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INTRODUCTION 


The initial installation of CP-67/CMS involves 
running CMS on the bare machine. CMS is used to load 
the CP-67 basic distribution tape onto a disk, read in 
the REALIO configuration and SYSDESCR module for the 
installation and assemble the REALIO, SYSDESCR and other 
modules, if necessary, to select the desired options. 
Once this is done, an EXEC procedure is invoked to punch 
the CP-67 nucleus, utilities, and loaders. The punched 
decks are then used on the bare machine to format the 
CP-67 volumes (sysres, drums, etc.) and to load the 
nucleus and directory on the residence volume. If CP-67 
is already installed, regenerations or new installations 
can be performed from a CMS virtual machine. 


The basic CMS system tape contains an [PLable 
dump/restore of a System disk. After restoring the tape 
file, a Primary disk is formatted. Using the restored 
System disk and formatted Primary disk, the CMS Source 
tape and the CP basic System tape can be read onto the 
Primary disk, and SYSGEN of the system can then be 
accomplished. 


The minidisk, or partial volume disk allocation, 
provides economical use of direct access storage space. 
Minidisks are available to both CMS and OS’ users, and 
can be used for both system residence and user-data 
volumes. Formatting of OS volumes is performed by the CP 
utility MINIDASD; the CMS FORMAT command is used for CMS 
volumes. In addition to formatting the disk for OS use, 
MINIDASD writes an appropriate VTOC which determines the 
amount of space available on the volume. Minidisks can 
be dumped to tape, and restored, using the CPDMPRST 
program, aS a means Of periodic backup. 


Version 3 Level 0 of CP-67 contained many new 
features that made it incompatible with previous 
versions. Version 3 Level 1 is an extension of Version 
3 Level 0. For this reason, utilities, loaders, or 
nucleus decks from releases prior to Version 3 must not 
be used. In particular, the real machine configuration 
description requires additional information to produce a 
valid RIO and SYSDESCR module. With Version 3 Level 1 
virtual machines are dispatched on the basis of their 
priority defined in the directory. 


SECTION 1: INSTALLING CP-67 


CMS FOR CP-67 SYSGEN 


To obtain CP~67, CMS is utilized. A description 
follows of how to obtain CMS and run it on the real machine 
(not under CP). This description is intended aS a 
convenient summary, aS more detailed information can be 
found under “Installing CMS". 


First, restore the DUMP/RESTORE copy of the CMS System 
disk. The CMS System tape contains the following files: 


file 1--IPL‘able DUMP/RESTORE 
file 2--a D/R copy of the CMS System disk. 
file 3--a tape-dump of the CMS System disk. 


Then, IPL the restored disk. Hit REQUEST on the 1052 
console if its real address is not X‘'009' or X'O1F'. CMS now 
allows you to reconfigure the CMS device address table to 
match the real device configuration of the installation. The 
following question is asked: 


01: REDEFINE ADDRESSES? (YES,NO): 
Answer YES, if the real addresses are different 
from the standard CMS virtual addresses listed 
below. | 


It is then necessary to enter the four-digit addresses 
for the following devices on the real machine if they differ 
from the address specified in the standard CMS device table: 
console, .S-disk, P-disk, reader, punch, printer, tape one, 
and tape two. In looking for the 1052 console when CMS is 
IPLed on the real machine, CMS looks for device 009 and then 
01F before waiting for the first interrupt denoting the 
console. 


Q2: WILL THE CP-SAVE FUNCTION BE USED? (YES,NO) : 
Answer NO to the CP-SAVE question. 


The standard CMS device addresses are as follows: 


Device Virtual Symbolic 

| Address Name 

1052 009 CON1 console 

2311, 2314 190 DSK1 system disk (read-only) 
2311 ,2314 191** DSK 2 permanent disk (user files) 





fo Be 
re 





** 


#2311 ,2314 192+** DSK3 temporary disk (workspace) 
*2311,2314 000** DSK4 A disk (user files) 
*2311,2314 000** DSK5 B disk (user files) 
*2311,2314 19C** DSK6 C disk (user files) 

1403 O0OE PRN1 line printer 

2540 00C RDR1 card reader 

2540 OOD PCH1 card punch 
*2400 180 TAP1 tape drive 
* 2400 181 TAP2 tape drive 
* The 2311 or 2314 for the temporary disk, the A, B, and 


Cc disks, and the two 2400 tape drives are optional 
devices; they are not included in the minimum 
configuration. 


The reference between the virtual address and I/O 


device may be changed at any time by the CMS LOGIN 
command. 


After entering the real device addresses, the CMS 
initialization message is typed 


CMS .. VERSION n LEVEL m 
Issue the CMS command 
FORMAT P ALL 
to format the P-disk to be used for CP-67 SYSGEN. The 


card punch and printer should be placed in READY 
status. 


Place the CP distribution tape on symbolic drive 
TAP2 and issue 


TAPE LOAD 4 
All necessary CP files are loaded onto the P-disk. 


These files are of the following filetypes for 
generation of CP-67 and the utilities: 


SYSIN files, which are the CP source decks written in 
Assembler Language; 


EXEC files, which contain procedures for assembling and 
updating; 


TEXT files containing the assembled modules of the 
system; 


MACLIB files containing CP-67 macros for assembling the 
system and the real machine configuration; 


ASP360 and COPY files for creating and changing the 
macro library CPMACS MACLIB, when necessary; 


LOADER files containing relocating loaders with 
different printer addresses (that is, 000, OOE, OOF, 
010, 030, O40): | | 


SAMPLE files containing examples of the various decks 
required for system setup. | 


It is from this P-disk (on which the above CP files are 
loaded) that the CP system is obtained. 


Note. While executing CMS onthe real machine, the last 
card of any punched deck must be manually run out from the 
card punch. | 


MACHINE CONFIGURATION DEFINITION 
| FOR CP-67 


A description of the physical machine must be provided 
for CP-67. This description is contained in a SYSIN or 
source deck called RIOxxx, where xxx are any three 
characters specified by the installation. This SYSIN deck 
1s assembled via the CMS ASSEMBLE command, and the resultant 
text or object deck placed in the CP-67 system. Same 
Simplex and duplex machine configurations are distributed 
among the P-disk files with the identifiers of RIOCSC SYSIN, 
SIMPLEX SAMPLE, and DUPLEX SAMPLE. If the distributed 


RIOCSC SYSIN does not meet the installation's configuration, 


a new RIOxxx deck must be constructed from the macros below, 
assembled, and used in place of the distributed RIOCSC text 
deck. | | 


To get the real I/0 definitions for the target 
configuration read onto the P-disk, from the card reader, 
place the RIOxxx deck into the reader, ready it, and issue 
the CMS command 


OFFLINE READ RIOxxx SYSIN 
where xxx are any three characters specified by the 


installation. If CSC is chosen for xxx, the existing file 
RIOCSC SYSIN is erased. 


To assemble the real I/O configuration deck, produce 
the text deck, and print the listing, issue the CMS command 








CPUPASM RIOxxx 


where xxx are the same three characters specified with the 
OFFLINE READ command. The TEXT deck is not punched but 
remains on the P-disk for the generation of CP. 


The physical (real) machine is described to CP via 
control blocks containing information about the input/output 
devices, channels, and control units. These control blocks 
are generated by the following CP-67 macros which are 
described below: REALIO, SIMPLEX, DRCH, DRCU, DRDEV, and 
DMXDV. 


The following conventions are used throughout this 
description: 1. variable information is indicated in 
lowercase and system key-words are indicated in uppercase 
letters, whereas both are written in uppercase when macros 
- are punched in cards; 2. < and > are used to bracket 
choices and the brackets) are not part of the macro 
definition (for example, RDEVPNT=<0,dlabel>) would be used 
to indicate that RDEVPNT=0 or RDEVPNT=dlabel could be used; 
3. a pair of |'s is used to indicate an optional parameter 
and the [|‘s are not a part of the macro definition (for 
example, SIMPLEX |n| would be used to indicate that SIMPLEX 
or SIMPLEX n could be used). 


MACHINE CONFIGURATION MACROS 
REALIO MACRO 


The REALIO macro is the first card of the deck. Its 
purpose is to generate the prerequisite entry points for use 
by the system and to give a CSECT name to the deck. Its use 
is 


jlabel| REALIO |TITLE="Listing Header' | 


where "label" becomes the alphabetic serialization of the 
text deck and title appears at the top of the pages in the 
listing. 

Note. label must be four or fewer characters. 


SIMPLEX MACRO 


The SIMPLEX macro follows the unit, control unit, and 
channel specifications for any given CPU. It provides for 
the creation of the necessary tables required by CP and is 
dependent on the configuration specified. If a simplex 


, 


configuration is described, the SIMPLEX macro must be 

followed by the END card. If a duplex configuration is being 

described, two SIMPLEX macros are required: the first 

SIMPLEX macro is followed by the I/O definitions for another 

CPU; the second SIMPLEX macro is followed by the END card. 
SIMPLEX |[n| 

where ‘n‘ is either null for a simplex system, ‘1° for the 


first half of a duplex specification, or '2' for the second 
half of a duplex configuration. 


I/O BLOCK DEFINITION MACROS 


The following macros are used to describe the physical 
input/output units available: 


Define Channel Macro 


[label] DRCH |CHANPNT=<0,chlabel>], 

RCULIST=List,CHANADD=c 
where "label" is the symbolic label of this channel; chlabel 
is the symbolic label of the next channel in the channel 


list; list is the symbolic label of the first control unit 
on this channel; and c is the channel address. 


Define Control Unit Macro 
[label] DRCU |RCUPNT=<0,culabel>|, 
DEVLIST=dlabel , RCUADD=c, 
| RCUPATH=<0, path>|, CUTAILI=taill 
where “label™ is the symbolic label of this control unit; 
culabel is the symbolic label of the next DRCU macro for the 


next control unit on this channel, if any; dlabel is the 
symbolic label of the first device defined for this control 








unit; cis the control unit address; path is the value 
(hexadecimal) of the logical path for this control unit 
(each control unit on a channel has a unique bit of the 
eight bits assigned to the channel andthis bit or path 
defines which devices are accessed through this’ control 
unit); taill provides a connection to this control unit from 
the channel--use the symbolic label of the channel on which 
this control unit resides. 


Define Device Macro 


[label| DRDEV’ |RDEVPNT=<0,dlabel>|, 
RDEVCU=culabel, RDEVADD=ccu, 
TYPE=type,DECUPTH=pa th, 


Where “label™ is the symbolic label for this device; dlabel 
is the symbolic label of the next device on this control 
unit; culabel is the label of the control unit on which 
this device resides; occu is the channel, control unit, and 
unit address of this device; type is the device type 
(specified as xxxx where xxxx iS 2311, 2314, =2321, 2301, 
2303, 2400, 1403, 2540P, 2540R, 2701, 2702, 2703, or 2250; 
"path" is identical to the control units path (RCUPATH in 
DRCU) for this device and defines which control unit this 
device uses. 


Define Multiplexor Device Macro 


Jlabel| DMXDV RDEVADD=ccu,TYPE=type, |SAD=n|, 
| RDEVPNT=<0, mlabel>| 


where “label“ is the symbolic label of this multiplexor 
device; ccu is the channel, control unit, and unit address 
of this device; type is the device type, which is. one of 
the following: 1052, 1403, 2540RDR, 2540PCH, 2701T, 2702T, 
2703T, or TT35T ( where the 2701T, 2702T, 2703T implies a 
1052, 2741-BCD or 2741-correspondence terminal coming into a 
2701, 2702, or 2703 and the TT35T is a teletype 33 or 35); n 
is the SAD address of the 2701, 2702, or 2703 and has a 
value of 0, 1, 2, 3, or 4 (the SAD address does not indicate 
terminal type); For a 2701 which does not require a_ SAD 
command, specify a value of 4. For a 2703 which ignores SAD 
commands, a value of 4 can also be specified. For a 2702, 
the correct SAD value for the particular line must _ be 
specified (0, 1, 2, and 3 are valid). Your local IBM CE 


nas ae 





can supply you with the SAD numbers for each 2702 line; and 
mlabel is the symbolic label of the next multiplexor device 
in the chain. There must be one DMXDV macro defined for each 
2701, one or 2703 line. 


Note. The ordered arrangement of the real I/O macros is. 
required to properly generate the correct entries and 
tables. 


The multiplexor devices must be defined before the 
selector channel devices. Each selector channel must be 
completely defined in terms of devices, control unit, and 
then channel (in that order) before the next selector 
channel is defined. If a simplex configuration is being 
described, the SIMPLEX macro must be followed by the END 
card. If a duplex configuration is being described, two 
SIMPLEX macros are required: the first SIMPLEX macro is 
followed by the I/0 definitions for another CPU; the second 
SIMPLEX macro is followed by the END card. 


An example of a real I/O source deck for a_ simplex 
configuration is as follows: 


RIOS REALIO TITLE=*SAMPLE SIMPLEX‘ 

OPCONSOL DMXDV RDEVPNT=PRINTER1 , RDEVADD=009, TYPE=10 52 
PRINTER1 DMXDV RDEVPNT=CARDRDR1 , RDEVADD=030 , TYPE=1403 
CARDRDR1 DMXDV RDEVPNT=PUNCH1, RDEVADD=031, TYPE=2540RDR 
PUNCH1 DMXDV RDEVPNT=TERM01 , RDEVADD=032, TYPE=2540 PCH 
TERM0O1 DMXDV RDEVPNT=TERMO2 , RDEVADD=020, TYPE=2702T, SAD=1 
TERM02 DMXDV RDEVPNT=TERMO3 , RDEVADD=0 21, TYPE=2702T,SAD=1 
TERMO3 DMXDV RDEVPNT=TERMO4, RDEVADD=023 , TYPE=TT35T,SAD=2 





TERMUYE DMXDV RDEVADD=04E , TYPE=27 03T, SAD=4 

DRUM 2 DRDEV RDEVCU=R2820A, RDEVADD=1 00, TYPE=2301, DECUPTH=80 

R2820A DRCU DEVLIST=DRUM2,RCUADD=0, CUTAIL1=CHAN1 , RCUPATH=80 

CHAN1 DRCH RCULIST= R2820A, CHANADD=1 , CHANPNT=CHAN2 | 

DISK30 DRDEV RDEVCU=R2314,RDEVADD= 230, TY PE=2314,DECUPTH=40, * 


RDE VPNT= =DISK31 


DISK31  $DRDEV RDEVCU=R2314,RDEVADD=231, TYPE=2314, DECUPTH= 40, = 
7 RDEVPNT=DISK32 


DISK37 Le ee ne ey ae 


R2314 DRCU DEVLIST=DISK30, RCUADD=3 , CUTAIL1=CHAN2, RCUPATH=40 

CHAN 2 DRCH RCULIST=R2314,CHANADD=2 , CHANPNT=CHAN3 3 Pc 
DRUM1 DRDEV RDEVCU=R2841B, RDEVADD=393, TYPE=2303, DECUPTH=80, * 

| RDEVPNT=DISK4 | | 
DISK4 DRDEV RDEVCU=R2841B, DEVADD=390, TYPE=2311, DECUPTH= =80, * 


RDEVPNT=DISK5 





> 
i ae 





R2841B DRCU DEVLIST=DRUM1 , RCUADD=9, CUTAIL1=CHAN3 , RCUPATH=80, 
RC UPNT=R2250 

SCOPE1 DRDEV RDEVCU=R2250, RDEVADD=306, TYPE=2250, DECUPTH=40 

R2250 DRCU DEVLIST=SCOPE1 , RCUADD=0, CUTAIL1=CHAN3 , RCUPATH=40 

CHAN 3 DRCH RCULIST=R2841B, CHANADD=3 , CHANPNT=CHANO 

TAPE1 DRDEV RDEVCU=R2400A, RDEVADD=0C0, TY PE=2400 , DECUPTH= 80 

RDE VPNT=TAPE2 

TAPE2 DRDEV RDEVCU=R2400A, RDEVADD=0C1, TYPE=2400, DECUPTH=80 

R2400A DRCU DEVLIST=TAPE1, RCUADD=C, CUTAIL1=CHANO , RCUPATH=80 

CHAN 0 DRCH RCULIST=R2400A, CHANADD=0, CHANPNT=CHANOA 

D2701A DRDEV RDEVCU=R2701A, RDEVADD=010, TY PE=2701, DECUPTH=80 

R2701A DRCU DEVLIST=D2701A, RCUADD=1, CUT AIL1= CHANOA, RCUPATH=8 

CHANOA DRCH RCULIST=R2701A, CHANADD=0, CHANPNT=CHANOB 

D2701B DRDEV RDEVCU=R2701B, RDEVADD=012, TY PE=2701, DECUPT H= 80 

R2701B DRCU DEVLIST=D2701B, RCUADD=1, CUTAIL1=CHANOB, RCUPATH=8 

CHANOB DRCH RCULIST=R2701B, CHANADD=0 

SIMPLE X 
END 

Note. Nonshared multiplexor devices, except for tapes, 
should be defined as separate channel, control unit, and 
device blocks (macros); that is, each device has its own 
set, as shown for D2701A and D2701B above. This’ avoids 


lock-out problems on that channel if unusual I/O operations 
are performed by users on a particular device. 


Further examples of REAL I/O configuration decks are 
available from the CP-67 distributed P-disk files: SIMPLEX 
SAMPLE, DUPLEX SAMPLE, and RIOCSC SYSIN. 


SETUP OF INSTALLATION PARAMETERS 


Installation parameters must be provided for CP-67 just 
as the machine description was provided. Installation 
parameters are described in a SYSIN deck called SYSDESCR, 
which is assembled and the resultant TEXT deck placed in 
CP-67. The SYSDESCR deck contains the following items: the 
SYSRES macro which describes the system residence volume, 
the SYSGEN macro which defines installation variables, a 
constant called SCREDAT which is the creation date and 
character string printed on the 1052 at system IPL, anda 
constant called SYSCHAR which is the character to be printed 
when CP console function mode is entered or a CP console 
function error occurs. A sample SYSDESCR SYSIN deck is 
distributed with the P-disk files along with the SYSDESCR 
TEXT deck. If the distributed SYSDESCR SYSIN does not meet 
the installation's needs, it should be altered as needed and 
reassembled as described for RIOxxx SYSIN in “Machine 


Configuration Definition for CP-67". 


The SYSRES and SYSGEN macros are described below. The 
SCREDAT and SYSCHAR constants are illustrated in the example 


below as well as in the distributed sample SYSDESCR SYSIN 
deck. i | | 7 7 | a 


SYSRES MACRO 


The SYSRES macro is used to describe the system 
residence volume. | [ts format is | : 


SYSRES SYSRES=ccu, SYSTYPE=ty pe, SYSVOL=vol id, SYSERR=aaa, 
SYSDNC=bbb, SYSWRM=ccc 7 


where ccu is the address of the disk onto which the nucleus 
is written; type is 2311 or 2314; volid is the CP-67 
formatted label of the volume (that is, CPDSK1); aaa is the 
cylinder allocated as permanent for error recording; bbb is 
the starting cylinder for nucleus residence; and ccc is the 
cylinder for warm start control. © a 3 


SYSGEN MACRO 


The SYSGEN macro is used to describe certain installation 


variables used for system operation. Its format is 


SYSGEN SYSOPER=userid, SYSDUMP=dumpi d, SYSEMRG=xxx, 
SYSCNSL=aaa , SYSPRT=bbb, SYSPUN=ccc, SYSCORE=dddK 


where userid is the operator's id for AUTO LOGIN; dumpid is 
the user's id for whom system dumps are made available from 
spooling files; xxx is the 270x line address for the 
emergency console startup; aaa is the system console 


address; bbb is the system line printer; ccc is the system 


punch, and ddd is the storage size of the real system 
a a in K. | | ey Oo 


An example of a SYSDESCR SYSIN follows: 


“SYSD -—«S« TITLE 'SYSDESCR> "VERSION 3, LEVEL 1° 


SYSDESCR START 0 | 
ENTRY SCREDAT | eo : 
_ De AL1 (SCREDATF-SCREDAT) LENGTH OF MESSAGE 
SCREDAT DC CL10'08/30/71° | | 
pe C'CP-67 Version 3 Level 1' 


{ 


SCREDATF EQU- * 


SPACE 1 — 
ENTRY SYSCHAR 


a 








SYSCHAR DC Cc*'cCP* 
SPACE 1 
DS OD 
SYSRES SYSRES=230,SYSTYPE=2314,SYSVOL=CPDSK1.... 
SYSGEN SYSOPER=CPSYS, SYSDUMP=00E, SYSEMRG=02F..... 
END 


In the above example, the SCREDAT field can be set to the 
date of system creation. This date and the following 
character string are printed on the 1052 at system IPL time. 


The SYSCHAR characters are printed to show the level of the 
virtual machine; that is, when the virtual machine is in 
console function mode, these characters are printed for 
command errors and verification. 


SELECTION OF SYSGEN OPTIONS 


Currently there are several options to be chosen during 
system generation: the real timer, the virtual 67, the 
statistical gathering/tracing options, and ISAM. To obtain 
the options, the file LOCAL COPY on the P-disk must _ be 
changed by using the CMS command EDIT. For each option there 
1s a corresponding statement in the LOCAL COPY file, for 
example: 


columns 1 10 16 
option name SETA 0 


AO or ‘NOS means the option is not selected; a nonzero 
numeric or ‘YES* in the operand field means the option is 
selected. Therefore, to obtain each option, the appropriate 
operand field must be chosen. Once the options have been 
selected, the corresponding CP-67 module must be updated and 
assembled by issuing the following CMS command: 


CPUPASM name 


Note. After the LOCAL COPY file has been edited for the 
selection of options, the COPY file must be placed in a 
MACLIB for access by the ASSEMBLER. To add the LOCAL COPY 
file to a MACLIB (for example, MACUP), issue the CMS command 


CPMACADD maclib LOCAL 


To replace it in an existing MACLIB (for example, CPMACS), 
issue the CMS command 


CPMACREP maclib LOCAL 


where maclib is the name of the macro library involved. 


The assembled modules distributed with this system 
contain the following options: 


ERTIMR SETA 6 
éV67 SETA 1 
6I1SAM SETC *YES* 
&TRACE(5) SETB 1 
&TRACE (6) SETB 1 


If these options are not desired or are to be changed, 
update the LOCAL COPY file and reassemble the modules 
affected, as described for each option below. 


Note: Use of these options affects system performance and 
Should be selected with care. The TRACE options involve 
especially heavy overhead. 





Real Timer--&RTIMR 


The real timer option &6RTIMR provides for updating a 
Virtual machines timer when the machine iS in wait state, if 
that virtual machine has the REAL TIMER option in the 
DIRECTORY. This option allows a dormant machine (for 
example, APL) to be awakened by a timer interrupt. (See 
"Directory Creation" for details.) 


The modules to be assembled for the 6&RTIMR option are 
DISPATCH and SCHEDULE. 


For the real timer option the SETA symbol is set to the 
number of concurrent real timers that the installation is 
willing to support. For instance, the statement 


€&RTIMR SETA 6 


produces code in the dispatcher to maintain up to six real 
timers. 


Virtual 360/67 Option--éV67 


The virtual 67 option, &6V67, provides code in the CP-67 
nucleus to support virtual machines in which CP-67 can be 
run. Those virtual machines with the virtual 67 option 
specified in the directory have the facility to operate in 
virtual extended PSW mode with 24-bit addressing. The 
distributed system has the 6V67 option selected. If the 
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option is not desired, change the LOCAL COPY value to 
&V67 SETA 0 


and use the EXEC procedure CPUPASM to reassemble the 
following modules: 


CFSMAIN 
DISPATCH 
ITOINT 
LOGON 
MVIOEXEC 
PAGTRANS 
PRIVLGED 
PROGINT 
QUEVIO 
RESINT 
PSA 
UNSTIO 
USEROFF 
VIOEXEC 


ISAM Option--&ISAM 


Certain OS /3 60 ISAM channel programs use a 
self-modifying operation which under normal CP-67 processing 
is not allowed. With the 6ISAM option selected, CP can 
detect the specific OS/360 ISAM channel programs and make 
changes inthe translated channel program to handle the 
self-modifying sequence. With the option selected and with 
the virtual machine using OS/360 ISAM, CP restricts somewhat 
the location of the ISAM CCW's. Four critical double words 
in certain channel programs cannot cross a page boundary. 
Refering to the OS/360 ISAM Program Logic Manual (Form 
GY28-6618) the following table lists the restricted channel 
program and the critical double words: 


Channel Program Critical Double Words 


CP1 C8, C9, C10, C10A 

CP4/5 CA12, CA13, CA14, CA1L5 
CP6 CA34, CA35, CA36, CA37 
CP8 CB10, CB11i1, CB12, CB16 
CP 23 CS6, CS7, CS8, CS9 

CP 23 CS17, CS18, CS19, CS19A 
CP 26 CS34, CS35, CS36, CS37 


Only those users with the ISAM option in the DIRECTORY 
have their CCW strings checked for self-modifying operation; 
thus not all users incur the additional CP overhead. This 
option is not needed for DOS ISAM. 


The module to be assembled for the &ISAM option is 
CCWTRAN. The distributed version has the option selected. 


If the option is not desired, change the LOCAL COPY 
value to | 


&ISAM SETC *nNo* 
and issue the CMS command 


CPUPASM CCWTRAN 


Statistical Gathering / Tracing--&TRACE 


This option is a binary array of 25 entries. Each 
element controls the _ selection of certain statistical 
gathering and tracing functions in cCP-67. The following 6 
elements are currently implemented. 


&6TRACE(1) SETB 1 
used in module PSA to trace CP-67 SVC calls in an SVC 
trace table in that module. To select the option, 
enter the statement in the LOCAL COPY file, update the 
MACLIB and CPUPASM the PSA SYSIN file. 


&6TRACE(2) SETB 1 

&6TRACE(3) SETB 1 
these two options control the tracing of selector and 
multiplexor interrupts (real hardware) respectively. 
The trace table and code selection is in the IOINT 
module. To select either or both options, enter the 
statements in the LOCAL COPY file, update the MACLIB, 
and CPUPASM the IOINT SYSIN file. 


ETRACE(4) SETB 1 | | | 
this option is used for FREE/FRET Statistical 
gathering. With the option selected, such data as 
number of calls, number of elements, etc. is gathered 
by the FREE module. To select the option, enter the 
statement in the LOCAL COPY file, update the MACLIB, 
and CPUPASM the FREE SYSIN file. | 


S6TRACE(5) SETB 1 (selected in the distributed system) 
this option is used to gather counts of user privileged 
instruction execution. The file STAT COPY defines the 
counters in low core that are used. To select the 
option, enter the statement in the LOCAL COPY file, 
update the MACLIB, and CPUPASM the files PRIVLGED 
SYSIN, PROGINT SYSIN and VIOEXEC SYSIN. 


&€TRACE(6) SETB 1 (selected in distributed system) 


this option is used to select the virtual machine 
tracing and address stop functions invoked with the SET 
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TRACE and SET ADSTOP console functions. To select the 
option, enter the statement in the LOCAL COPY file, 
update the MACLIB, and CPUPASM the files PSA SYSIN, 
PROGINT SYSIN, VIOEXEC SYSIN, UNSTIO SYSIN, DISPATCH 
SYSIN, RESINT SYSIN, TRACER SYSIN, and CFSSET SYSIN. 


The &TRACE elements 7 through 25 are reserved for future 
use. 


Note. The above procedure for options can also be applied 
to code added by an installation. The module can be 
assembled to selectively contain the installation's code 
(1) by placing a COPY OPTIONS and a COPY LOCAL instruction 
before the START card in the module being modified, (2) by 
adding a SETA instruction in the LOCAL COPY file, that is, 


&6LOCAL1 SETA 1 


(where &LOCAL1 might mean all local modifications made by 
programmer number 1), and (3) by checking for the setting of 
the option in the module. 


OBTAINING CP-67 


To obtain the tailored CP-67 system, a card load deck 
must be punched out and then loaded onto a properly 
formatted volume. To punch the CP card load deck, the CP 
utilities and card loaders, verify that the card punch is in 
READY status, then issue the CMS command: 


CPGEN 6&1 6&2 
where 


61 is the address of the printer that the loader 
uses to print the CP load map. A loader 
called RELDRxxx punches at the start 
of the deck, where xxx, specified in 61, is 
the printer address in 3 hex characters 
(for example, OOE or 030). 


&2 is the full name of the real I/O configuration deck 
that was specifically assembled for the system 
in the procedure above (for example, RIOCSC or 
RIOABC). 


The above command punches out the complete CP load deck 
(about 2500 cards with each text deck uniguely identified in 
columns 73-75) and each deck is separated by an identifying 
card with the format 


OFFLINE READ fname ftype 
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where fname is the object deck filename and ftype is TEXT. 


Note. There is a pause after punching the CP-67 LOAD DECK 
to allow the user to clear the punch and get the last card. 
The user can continue by typing "“ready™ or he may stop here 
by typing "quit". This is clearly stated on the terminal as 
the CPGEN operation proceeds. | - | 


OBTAINING THE UTILITIES 


The utilities supplied with CP-67 are as follows: © 


BUZZARD 
DIRECT 
FORMAT 
SAVESYS 
VD UMP 
FDUMP 
EDITDUMP 
MINIDASD 
CPDMPRST 
SAVEOS 
- CPIPL 


The CP utilities are punched out as part of the CPGEN 
procedure above. The second file output contains all the 
utilities, each identified by a deck separator of the 
OFFLINE READ form (as outlined above for the CP load deck). 


The CP utilities, BUZZARD, FORMAT and  SAVESYS, are. 
stand-alone programs and must have the appropriate loader on 


the front that reflects the correct printer address. The 


DIRECT utility runs stand-alone or under CMS. If it is run 
Stand-alone, it requires a loader. The VDUMP utility runs 
only under CMS. It is used to retrieve CP-67 dumps from 
disk after an ABEND in the CP supervisor. The VDUMP utility 
is run by the user specified in the SYSGEN macro of SYSDESCR 
as the SYSDUMP parameter. In addition to the standard CMS 
machine configuration, the user must also have a_ reader 
printer device in his virtual machine as | | 


ONIT OF1,RPRT 


in order to run VDUMP. See “Obtaining CP-67 Dumps--VDUMP" 
for details. 7 


SAVEOS and CPIPL are OS programs, to be run in an OS virtual 
machine, and are equivalent to SAVESYS for an OS system. 
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The CMS files for implementation are: SAVEOS JOB, SAVEOS 
SYSIN, and CPIPL SYSIN. Reference Operating Systems ina 
Virtual Machine for further information. 


See the CP-67 Operator's Guide for a description of 
CPDMPRST, a CMS program that dumps and restores 2311 or 2314 
volumes between disk and tape. 


Detailed descriptions of each of the other utilities are 
found in the ensuing sections. 


To obtain copies of the loader, issue the CMS command 
OFFLINE PUNCH name LOADER 


where name is either RELDROOO, RELDRO10, RELDRO30O, RELDROOE, 
RELDROOF, or RELDRO4O, depending on the real address of the 
printer. 


If an installation has a printer of any other address, 
use the RELDROOO LOADER and immediately after the loader and 
before the TEXT file(s) to be loaded place the following 
control card: 


column 1 2 6 10 
CTL WIR ccu 


coiumn 1 - 12, 2, 9 punch 


where ccu is the desired printer address. 


The CPGEN procedure punches out three loaders’ for the 
specified printer address 6&1 (that is, OOF) to be used with 
various loading functions and also three loaders with a zero 
address (RELDROO0O), which are useful when loading the CP 
utilities. 


Note. If a loader RELDROOO is used, no load map is 
produced, but the loading function proceeds. A load map is 
very useful for the CP-67 system, but of little use when 
loading the utilities, thus RELDROOO can be used by an 
installation to load a program without using the printer. 





FORMATTING OF VOLUMES 


Once the CP utilities have been punched out, the 
direct-access volumes used by the system (for paging, 
spooling, nucleus residence, and directory) must be properly 
formatted. This is accomplished by means of the FORMAT 
utility. The detailed instructions for operating FORMAT 
follow. 


a (i fee 


After the operator's console has been identified, it 
types | 


CP/67 DASD FORMAT PROGRAM 


Then it requests the type of device being formatted by 
typing | | 


‘DEVICE TYPE 


where the response may be four digits indicating the type of 
device (that is, 2301, 2303, 2311, 2314) and an optional 
fifth character, p, which causes only partial formatting to 
take place (that is, 2314p). | 


If the device type is recognized, the system requests 
the unit address 


DASD ADDRESS = 


where the response is the channel and unit address as three 
hexadecimal digits (for example, 100, 1C0O, 230, A30, 9C0). 


If the device is ready, the system asks for the new 
label to be written by typing | 


VOLUME LABEL = 


where the response is Six characters (uppercase or 
lowercase) written on the label record of the volume. 


If p was specified when indicating device type, the 
System now asks the operator to define the area to be 
formatted by typing 


START CYL. (HEX) = 
where the response is null for cylinder 0, “lo™ if only the 
label is to be written, or two hexadecimal digits specifying 
the starting cylinder. The system then requests the ending 
cylinder by typing | 

END CYL. (HEX) = 


where the response is null for the entire volume (whose 
actual value differs with the device type) or two 
hexadecimal digits for a specific cylinder. | 


x 26. 
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The system indicates that the format operation has 
commenced when its data is complete. At termination, the 
program will so indicate and may be restarted by pushing 
REQUEST. 


The system's residence volume for CP is usually 
formatted with the label CPDSK1, as that label is required 
for IPL‘ing by name. If it is desired to change the volume 
label, the file SYSTEM SYSIN must be modified to reflect the 
desired system's residence volume label and SYSTEM SYSIN 
must be reassembled and replaced in the CP load deck. 


ALLOCATION AND DIRECTORY CREATION 
Allocation 


All 2314 and 2311 volumes to be used for CP-67 spooling 

and/or paging must have space allocated. The system 
residence volume must have space allocated for the system 
directory and the nucleus. 
Note: 2301 and 2303 drums must not be allocated since they 
are specially formatted for dynamic paging allocation. The 
DIRECT utility (ALLOCATE control cards) is used to allocate 
Space for the system residence volume and others, if 
necessary. For 2314 residence, the following space must be 
allocated as permanent: 


Cyl. Usage 


0 IPL and file directory 

* SYSERR * error recording (1 cyl required) 

"SYSWRM* warm start control (1 cyl required) 

"SYSDNC°* nucleus residence (2 cyl required) 
to *“SYSDNC+1* nucleus residence 


The values for the symbolic cylinder locations are 
defined in the SYSDESCR deck with the SYSRES macro. 


For 2311 residence, the following space must be 
allocated as permanent: : 


Cyl. _ Usage 


O-1 IPL and file directory 

* SYSERR * error recording (1 cyl required) 

*“SYSWRM* warm Start control (1 cyl required). 

*SYSDNC° nucleus residence (5 cyl ESdeEee 
to *SYSDNC+4*" nucleus residence 
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The symbolic values are obtained from the SYSRES macro 
specified in the real machine configuration description. 


Cylinder 0 and others may be allocated as DRCT space. 

In addition, some cylinders may be allocated as permanent 

for user file space or named system residence. Other | 
cylinders must be allocated as TEMP (for spooling or paging) 

or TDSK. | | : 


CP-67 requires an allocation record to be written behind 
the volume label on cylinder 0 head 0 record 3 of each disk 
that is to contain space for the directory, paging, and 
spooling. The allocation record specifies which cylinders 
on the disk are used aS permanent space and which are 
temporary space. Permanent space on a volume consists of 
the areas reserved for user files and system residence. 
Temporary space consists of those areas used for paging and 
spooling by CP-67. 


There are five types of allocation control cards: 
ALLOCATE, DRCT, TEMP, TDSK, and PERM. The format of the 
ALLOCATE card is 


ALLOCATE UNIT=ccu, VOLID=xxxxxx 


ccu is the address of the device to be 
allocated. 





XXXXXX 1S the six-character label of the volume 
to be allocated. 


ALLOCATE must start in column 1 and UNIT in column 11. 
DRCT space is used for CP-67 directory residence. 
TEMP space is used for CP-67 spooling and paging. 
PERM space is for user direct-access files. 
TDSK is’ for DASD units in the user machine 
descriptions that are to be allocated at login time 
from a pool of temporary disk space. The TDSK area 
is not used by CP for spooling and paging. | 
The control cards for the allocation of space are 
DRCT XXX ZVVY 
TEMP XXX ~/VVY 


PERM XXX VVY 
TDSK XXX *VVY 
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where DRCT, TEMP, PERM and TDSK start in column 10, and the 
cylinder designations in decimal form (with leading zeros to 
make three characters each) start in column 16. xxx is the 
first cylinder and yyy is the last cylinder. 


There must be one ALLOCATE card for the CP residence 
volume and for each disk that contains temporary space (TEMP 
and TDSK). Each ALLOCATE card must be followed by the 
control cards for that volume. When all the allocation for 
a device has been specified, the following card is used to 
indicate the end of allocation cards for the volume: 


* FOA* 


The *EOA* begins in column 10. The *EOA* card is then 
followed by another ALLOCATE card or a DIRECTORY card. 


Note that the system always makes cylinder 0 permanent 
for the volume label and allocation table residence. 
Therefore, do not begin user files on real cylinder 0 of 
those disks that are being allocated. Checks are also made 
for exceeding device limits on the device address specified. 


The allocation of volumes can be a separate run from 
that of the directory. Also, each volume can be allocated 
independently of the others. 


The directory must be created after the direct-access 
volumes are properly formatted. A sample directory is 
contained on the P-disk in the file DIRECT SAMPLE. To obtain 
a printout of that file, issue the CMS command 


OFFLINE PRINT DIRECT SAMPLE 


The directory is created by the utility DIRECT, the 
instructions will be found in the next paragraphs. The 
allocation of Space on the residence volume (as described 
above) must precede the directory creation. 


Directory Creation 


The CP system residence volume must contain a directory 
that describes the users and their virtual machine. The 
directory portion of this utility accepts the descriptions 
of the users and their virtual machines from the card reader 
specified at the operator's console and writes the directory 


in the ienpoeaEry space previously allocated on the system 
residence volume (initially the disk must be formatted 
before ALLOCATE'ing and DIRECTORY take place). Depending 
upon the size of the directory and the device type of the 
System residence volume (that is, 2311 or 2314), at least 
the first two or three cylinders should be allocated as DRCT 
‘Space on the CP system residence volume. Estimates on space 
requirements for the system directory are as follows: 


2314-- 150 USER virtual machine 
_ descriptions per cylinder 


2311-- 40 USER virtual machine 
descriptions per cylinder 


These space requirements are in addition to eylinder 0 of 
the residence volume, which is used as the master directory. 
Thus, the directory allocation control card, 


DRCT 000,003 


is “wigeeieient to provide space on aieee cylinders (1, 2, and : 
3) for virtual machine descriptions. 


Every user who is to be permitted to log in to CP-67 
must be described in the directory, including the system 
operator. | | 


The directory description must begin with the following 
control card: 


DIRECTORY UNIT=ccu, VOLID=xxxxxx 


ccu is the real address of the CP system's 
residence volume on which the directory 
is to be written. 


XXXXXX is the Six-character volid of the disk on 
which the directory is written. 


- DIRECTORY must start in column 1 and UNIT in column 11. 


After the DIRECTORY control card comes the OWN card. 
its format is * | 7 


where “aaaaaa,bbbbbb, ... ,hhhhhh" are the volume labels of 
disks that contain allocation tables. OWN must start in 
column 10 and the volume labels in column 16. Only eight 
labels can be specified in one card. To name more than 
eight, use multiple OWN cards. A maximum of 40 owned volumes 
is allowed. } 
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Note that the only volumes specified in the owned list 
are those that CP can use for TDSK allocations, paging and 
spooling, such as drums, and the system residence volume. 
Volumes that have no TEMP, DRCT, or TDSK space (for 
instance, OS, DOS, CMS volumes) should not be in the owned 
list, as it is obviously not necessary to allocate volumes 
that are all PERM space. 


Next are the cards that describe a user and his virtual 
machine. These cards are described below. (Note that the 
label field always starts in column i1, the operand field, 
that is, card type, in column 10, and the arguments in 
column 16.) 


userid USER password, account, priv-class, priority, options 


The USER card initiates a new machine description file 
and creates a user directory entry for the specified user. 


"“Userid™ is the eight-character external name by which 
the user andall spooling output are labeled; it must be 
left-justified and trailing blanks included if userid is not 
eight characters. 


"Password" is the key by which the user must respond 
when trying to login to the system. The password must be 
Specified as eight characters, left-justified, with trailing 
blanks if eight characters are not specified. Note that if 
the terminal has the print inhibit feature, the system turns 
off the printing mechanism to maintain the security of the 
password, or if the user issues the LOGIN command with a 
mask character, one line of overprinting occurs before the 
user is allowed to enter his password. 


"Account" iS any eight-character identification for 
installation accounting uses. 


"“Priv-class™ is the user's privilege class: A _ for 
System operator, B for system administrator, C for IBM 
customer engineering use, and D for normal users. This 
privilege class determines what console functions in the 
system the user may exercise. (See Appendix A in the CP-67 
Operator's Guide for a table of console functions available 
to each privilege class.) 


Note: Users with privilege class C do not have I/O errors 
recorded for them by cCP-67. Use of this class’' should 
therefore be carefully restricted. Privilege class C can 
also execute certain DIAGNOSE functions to maintain the 
error-recording cylinder. 
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"Priority" is used by the dispatching scheme. The 
decimal number may range from 00 - 99, with 00 being the 
highest priority. | | : 


| "“Options™ is a hexadecimal number that selects 
specific options available to users at login time and 
execution time. There are currently three user options 
available. (See “Selection of SYSGEN Options") They, and 
ed hex ve veSs are: | 


REAL timer suspere | X80" 
ISAM support  X* 40% 
VIRTUAL 360/67 support X*20° 


Note: The &ISAM option allows the user to do I/O operations 
as used by OS/360 ISAM. It is not required for DOS ISAM. 


Multiple options can be selected by combining the 
values. For instance, real timer and virtual 67 would be 
Specified as 


ee @ USER Meee gh AO" | 


The core card specifies the size of the user's virtual 
memory . 


dddd | 
CORE | dddaK | 
| adam | 


It may be specified as dddd where dddd is a decimal number. 
that is a multiple of 8192 bytes, or by one or more decimal 
digits followed by kK or M, indicating a multiplier of 1024 
bytes or 1,048,576 bytes respectively. The core size must 
be a multiple of 8K, where 8K is the minimum. When a user 
lojs in to CP-67, he receives a virtual machine of this 
Size. Paging space is not selected for this virtual machine 
until the user references core storage; space on the paging 
device is then selected one page at a time. If a user does 
not need a large core space, allocate him a small one--for 
example, give the system operator 8K core. 


UNIT ccu ,devtype 
| <XXXXXK, (TEMP) , REM=IDecu, CON=YES, DED= =IDccu>| 
| <relno,zzz>] 
| last} 


| ,-RDONLY | 
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| ,RDSHAR=password | 
| ,WRMULT | 


| -WRSHAR=password | 


The UNIT card is used to specify the input/output units 
available to a user and where andon which volumes his 
permanent files reside. 


ccu is the virtual address of the device. 


devtype is the device type, which may be one of 
the following: 


1052 

2540P 

2540R 

1403 

2250 

2311 or 2312 
2314 


where a 2312 is used to designate the 
bottom half of a 2314 drive used as a 
Virtual 2311. 


A 2312 device type is treated as a 2311 by CP-67. User seek 
commands issued to the pseudo 2311 have the head address 
relocated (by adding decimal 10) to access the bottom half 
of the 2314 disk. It should be noted that 2311 device types 
Supported on the top half of a 2314 pack may experience 
difficulties if multitrack operations are attempted; 
however, multitrack operations onthe 2312 (pseudo 2311) 
device type Should work correctly since a physical 
end-of-cylinder condition is recognizable. 


TIMR is a pseudo-timer device which can provide the time of 
day, date, virtual CPU time, and total CPU time to a virtual 
machine. It should be specified for every CMS user. Its 
format is 


UNIT OFF,TIMR 


RPRT and RPUN are special device types that allow the user 
to access the disk dump created by a CP-67 system abend. 


For the desired userid to receive the dump (see section on 
VDUMP) specify 


UNIT OF1,RPRT 


XXXXXX is the volume label of the disk that is being 
descr ibed. 
(TEMP) specifies that the disk space is to be 


obtained at logon time from that allocated as TDSK 
space and then removed from the user at CP-67 
_ logoff. 


REM=IDccu specifies a remote device with real address 
ccu that is to be used for spooled output from 
this defined user. It has the same function as 
the SPOOL console commands for directing spooled 
output. See CP-67/CMS User's Guide for details. 
The only device types supported as remote devices 
are the 2540P and the 1403. 


DED=IDccu specifies a device with real address ccu that 
is dedicated to this user at login time and 
unavailable to other users. The device types 
supported are the 1403, 2540R, 2540P, 2250, 2400, 
2701, 2702, and the 2703. If the specified device 
is not available or in use when the user logs in, 
he is so informed and the device is not attached 
to him. Note that a 2250 or 2400, if specified, 
must be defined as a dedicated device. 





CON=YES specifies that continuous spooled input is 
desired for this virtual card reader; that is, if 
there is more than one spooled input file for the 
card reader, they are read as one continuous file 
before end-of-data is given. This has the same 
function as the SPOOL ccu CONT console function 
‘(see CP-67/CMS User's Guide for details.) 


relno is a three-digit decimal cylinder relocation 
factor to be applied to this device; for example, 
if a user's permanent files started at cylinder 54 
of the specified volume, relno would be specified 
as 054. 


ZZz 1s a three-digit decimal number specifying the 
number of temporary cylinders to be obtained at 
logon. zzz is used only if (TEMP) was specified. 


last is a three-digit decimal number specifying the 
last cylinder of the user's file space. If relno 
is 054 andthe user is allowed 20 cylinders of 
space, last would be specified as 073. 
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RDONLY specifies that the virtual direct-access 
volume can only be read and not written upon. If 
RDONLY is not specified, the user has read/write 
access to the volume by himself, and no other user 
can read or write that volume unless WRMULT is 
specified for those users. (See WRMULT.) If the 
volume being described is the CMS system disk, 
RDONLY should be specified for each user. 


RDSHAR=password is a one to eight-character 
password that allows this volume to be shared for 
reading by users knowing the proper password. If 
ALL is specified as a password, all users have 
access to the volume for read-sharing. RDSHAR is 
only used for permanent volumes and not temporary 
ones. If either WRSHAR or WRMULT is specified, 
but not RDSHAR, a comma must be used to show that 
RDSHAR is omitted. 


WRMU LT allows the user to have access to the volume 
regardless of other users. If WRMULT and RDONLY 
are both specified for a user's volume, he will 
have read-only access to that volume, regardless 
of other users. If only WRMULT is specified, he 
has read/write access regardless of other users on 
that same volume. This parameter is intended for 
use by users using operating systems which provide 
an interlocking mechanism to protect files or for 
systems programmers who know what they are doing. 
CMS does not have an interlocking mechanism. 


WRSHAR=password is a one to eight~character 
password that allows the volume to be shared for 
writing as well as reading, but only one user can 
have access to the volume at a time. The volume 
is shared among users knowing the proper password. 
If ALL is specified as a password, all users have 
write-sharing privileges on the volume. 


Note. RDONLY is inconsistent with WRSHAR and consequently 
they may not be specified together. If RDONLY is specified 
on a volume for all users but one, and that one user logs in 
first, he will use the volume in a read/write status and 
Other users will have no access to that volume unless they 
have the WRMULT parameter. When the RDONLY users’ log in, 
they receive the message 


DEV ccu IN USE BY userid; NOT ATTACHED 


The RDONLY users should either log out and then log back in 
or issue LINK console function after userid logs out or 
userid detaches that device from his virtual machine. If 
that read/write user logs in after a RDONLY user, he will 


receive the message 
DEV ccu IN USE BY userid; SET TO R/O 


and he will have read-only access to that volume. The 
userid will be one of the RDONLY users who logged on first. 


If a read/write WRMULT user logs in after a RDONLY or a 
read/write user, the WRMULT user will have read/write access 
regardless of the other users on that volume, and he will 
receive the message 


DEVICE ccu IN USE BY userid 


If a RDONLY, WRMULT user logs in after any other user, he 
has read-only access to the volume, regardless of other 
users, and he receives no message. | 


The parameters specified with the UNIT control card are 
positional, therefore they must be specified in order and a 
comma must be used for each parameter omitted. 


Each user's machine description is terminated by a card 
with | | | | 


* EOU* 


beginning in column 10. At the end of all user directory 
descriptions, a card with | , 


*EOD* 


beginning in column 10 is used to terminate the directory 
creation process and to return to the ALLOCATE and DIRECTORY 
card-scan routine. If there are no additional ALLOCATE or 
DIRECTORY cards, DIRECT is terminated; if there are 
additional ALLOCATE or DIRECTORY cards, DIRECT is executed 
again. | 


A sample allocation and directory deck are as follows: 


ALLOCATE UNIT=230,VOLID=CPDSK1 
DRCT 000,003 
PERM 004,004 
TEMP 005,197 
PERM 198,202 
+EOA* 
ALLOCATE UNIT=235, VOLID=CPDSK5 
PERM 000,000 
PERM 001,075 
TDSK 076,165 
PERM 166,202 
+*EOA* 








DIRECTORY UNIT=230, VOLID=CPDSK1 


OWN CPDSK1, CPDRO1,CPDSK5 
OPERATOR USER CSC 7A1234 7A, 80 
CORE 8K 
UNIT 009,1052 
*EOUF 
USER1 USER PASS1 g222 7D, 30 
CORE 256K 
UNIT 009,1052 
UNIT OOE,1403 
UNIT 00C,2540R 
UNIT 0O0D,2540P 
UNIT OFF,TIMR 
UNIT 190,2314,CMS190, 000,053, RDONLY 
UNIT 191,2314,CPDSK5,166,175 
*EOU* 
USER2 USER PASS2 7 A590 eC, 30, X* 80° 
CORE 256K 
UNIT OOE,1403, DED=ID030 
UNIT 009,1052 
UNIT 00C,2540R 
UNIT 00D,2540P 
UNIT 106,2250,DED=ID106 
UNIT OFF,TIMR 7 
UNIT 190,2314,CMS190, 000,053, RDONLY 
UNIT 191,2312,CPDSK6,148,152,, ,WRMULT 
UNIT 193,2311, KVR999,000,202 
*EOUF 
USER3 USER PASS3 ,X3214567,C, 30, X'CO0' 
CORE 256K 
UNIT 009,1052 
UNIT O0E,1403 
UNIT 00D,2540P 
UNIT 00C,2540R 
UNIT 190,2314,CMS190, 000,053, RDONLY 
UNIT 191,2314,CPDSK3,050,060, , RDSHAR=RDXX eWRMULT 
UNIT 192,2314,CPDSK5,001,075,,,,WRSHAR=MYPASS 
*EOU* 
* EFOD* 


CREATION OF PERMANENT RESIDENCE VOLUME 


Once the volumes have been formatted and the directory 
created, the permanent CP residence nucleus’ should be 
created from the CP LOAD DECK. The last module in the CP 
load deck is the SAVECP module (serialization SCP). The 
function of this module is to create, after the load through 
the card reader, an IPL‘able copy of CP on the residence 
volume from the core image. The volume address, label, and 
nucleus cylinders are indicated to SAVECP from information 
contained in the RIOxxx module, in particular, the 
information from the SYSRES macro. 
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To create the permanent CP residence volume, ready the 
CP load deck into an available reader. The first module in 
the load deck must be the relocating loader, which prints 
the load map of the system onto the printer. Perform an IPL 
sequence on the card reader. The volume must be mounted and 
ready before the load completes. [t is advisable to clear 
core before loading. If the disk is not ready, the message 


*#%**%* DISK CUU NOT READY **** | 

is printed. 

If the label on the disk is puececect. the message 
**#%*%* VOLID NOT dlabel *eX 

is printed. 


If either message is printed, remedy the situation and press 
the EXTERNAL button to retry, or start from the card load. 


At the termination of the load and the creation of the 
residence volume, the following message appears on the 
operator's terminal: | 


DISK LOAD OK 


At this time, the permanent CP residence volume has been 
created and may be IPL‘ed to initiate system operation. 


OBTAINING CP~67 FROM AN EXISTING CMS 


For those installations that have an operating 
CP-67/CMS system, the CMS restore procedure outlined above 
can be bypassed. The following steps can be used to obtain 
CP- 67: 


1. Mount the distribution tape on an available tape 
drive attached to the desired userid as '181"'. 


Ze Using CMS issue a TAPE LOAD 4 command. The four 
files will then load in their entirety onto the user's 
P-disk space. 


Note. About 50 cylinders of 2314 space are adequate to 
hold all the files and do assemblies. 





3. Perform any necessary assemblies for configuration 
or options as outlined under “Setup of Machine 
configuration" and “Selection of SYSGEN Options". 
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4. Follow the procedure under “Obtaining CP-67" using 
the CPGEN command. 


5. BE SURE TO USE THE VERSION 3 UTILITIES AND LOADERS 
WITH VERSION 3 OF CP-67. 


GENERATING "NAMED" OPERATING SYSTEMS 
UNDER _CP-67 


Providing a user with the capability of performing an 
IPL function by name, rather than by device, requires the 
installation to save a copy of this system on a DASD device 
in paging form. The self-loading deck which performs this. 
is entitled SAVESYS. It accepts a control card of the form 


SAVE VOLID=cccccc ,UNIT=ccu, FP=nn, LP=mm, CYL=ppp, DISK=tttt, 
TRK=hh | | 


where 
SAVE must begin in column 1; 
VOLID must begin in column 6; 


cccccc is the volume label of the receiving DASD 
volume, which must have been formatted by CP FORMAT; 


ccu is the channel, control unit, and device address of 
the receiving volume; 


nnis the page number of the first page to be written 
(in hexadecimal); | : 


mmis the page number of the last page to be written 
(in hexadecimal). 


ppp is the starting cylinder of the image; this isa 
real address, that is, a minidisk cannot be used; 


tttt is the device type (either 2311 or 2314). 


hh is the starting track number of the image. If 
omitted, zero is assumed. If specified, it must be an 
even track number. 


Note: Be sure that the parameters on the SAVE card 
correspond with those defined inthe SYSTEM and SWPTABLE 
macros in the SYSTEM module. 


The space indicated on the card must have been previously 
allccated as permanent space on the volume. The information 
on the control card must match that information provided in 
the SYSTEM module assembled and loaded with the system. In 
that module the system name, location, shared pages, if any, 
and operating conventions are established. In the 
distributed SYSTEM module, the system name is CMS, and 
eighteen pages are saved, beginning at page 0, up to and 
including page X‘'11". The saved copy of CMS is written on 
the 2314 volume labeled CPDSK1 at cylinder 200. | 
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The SYSTEM SYSIN file is constructed using a SYSTEM 
macro, which has the format 


SYSTEM NAME=nnn,FIRSTP=aa,LASTP=bb, TABLE=ttt, 
VOLID=xxx , EXADD=ccc, SYSMAS K=sss, RUNKEY=kkk, 
SYSTAB=yyy 


where 


nnn is the name for the system; 

aa is the first page saved; 

bb is the last page saved; 

ttt is the label of the SWPTABLE macro 
associated with this system; 

xxx is the label of the volume on which the 
system is saved; 

ccc is the virtual machine execution address; 

SSS is the virtual machine system mask; 

kkk is the virtual machine protection key; 

yyy is the label of the shared page table 
in PAGTRANS if this system has shared 
pages; otherwise it is zero. 


The SWPTABLE macro used with the SYSTEM macro has the 
following format: 


ttt SWPTABLE DASDORG=ccc, FIRSTP=aa,LASTP=bb, 
FIRSTSP=xx, LASTSP=yy, DISK=ddd 


where 


ttt is a label (same as ttt in SYSTEM macro); 

ccc is the cylinder address where the system is saved; 
aa is the first page saved; 

bb is the last page saved; 

xX is the first shared page, if any; 

yy is the last shared page, if any; 

ddd is the disk type where saved, 2311 or 2314. 


The SYSTEM macro builds a table to define the name and 
running attributes of the saved system. The SWPTABLE macro 
builds a model SWPTABLE that is mapped to the virtual 
machine SWPTABLE in core to give that machine access 
(through paging) to the saved system. 


Pages defined as shared in SWPTABLE are automatically 
LOCKed in core once the saved system is IPLed; they remain 
locked until nobody is using the saved system. 


The number of cylinders required to hold a named system 
depends upon the number of pages saved and the device type. 
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For a 2314, one cylinder holds 30 pages; a 2311 cylinder 
holds 8 pages, Thus, CMS with 17 pages requires one 2314 


cylinder or three 2311 cylinders. 


Models of the SYSTEM and SWPTABLE macros are given below, 
The named system “OS™ will be saved starting at real 
cylinder address 86 on the 2314 volume CPVOL1. 64 pages 
will be saved. When ipl-ed, execution will begin at X‘'88". 


SYSTEM NAME=OS,FIRSTP=00,LASTP=3F, 
TABLE=OSTBL, VOLID=C PVOL1, 
EXADD=88, SYSMASK=00, RUNKEY=00 
OSTBL SWPTABLE DASDORG=086, FIRSTP=00, 
LASTP=3F , DISK=2 314 


When SAVESYS saves a copy of the system, it saves from 
FP to LP. If LP is greater than X'20‘', the SAVESYS module 
must be loaded into higher core, as it normally loads into 
X*20000". To load SAVESYS into higher core, change the 
address in the SLC 20000 card at the front of the SAVESYS 
text deck. 


The procedure for creating the page-form copy is as 
Follows: | 


1. Load the required system into memory, with an address 


stop set to a location within that system where 
execution may be resumed without the system assuming 
any previous state in the machine (that is, registers, 
lower core locations, etc.). For CMS the address stop 
location is X‘'88*. | 


2. ATTACH the direct access device on which the system is 


to be saved to the virtual machine being used. The 
cylinders on which the saved system is to be stored 
must be formatted for CP file residence by the CP-67 
utility program FORMAT. Follow the procedures outlined 
in this manual under “Formatting of Volvmes". For the 
purpose of formatting an area which will hold a 
pageable copy of OS, the full volume must be ATTACHed, 
and the cylinder addresses specified must be real 
(i.e., it is not possible to use a minidisk). Do not 
attempt to use a 2301 or 2303 as the FORMAT program 
initializes those devices for dynamic paging only, and 
makes them unsuitable for saved system storage. Note 
that FORMAT will write a CP-67 volume label at cylinder 
0, record 3 of the receiving volume. 


If the saved system is to be stored on a CP system disk 
(one that is available to CP for paging, spooling or 
CMS Temporary file space), then the CP utility program 
DIRECT must also be run. In the allocation control 
cards which are input to DIRECT, specify that the 
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cylinders to be used for the saved system are permanent 
by supplying an appropriate PERM control card; refer to 
the section entitled “Allocation and Directory 
Creation". Note that DIRECT will allocate cylinder 0 of 
the receiving volume for its allocation tables. 


3. When the system has entered manual state (that is, the 
address stop has’ been reached), load the SAVESYS deck 
into the system card reader and load from the reader. 


The format of the SAVESYS deck is as follows: 


High core loader 

SLC 20000 card 
SAVESYS program 

LDT card 

SAVESYS control card 


4. If the save was successful, a message appears on the 
operator's terminal to that effect. 


Note. The following procedure must be used to run 
Version 2 of CMS under Version 3 of CP as’~ the named 
system CMS: either the SYSTEM module must’ be changed 
in CP, as Version 2 of CMS has only 3 shared pages, or 
the saved copy of Version 2 of CMS must be given a name 
other than CMS. 


See “Saving CMS under CP-67" in this manual for 
details of preparing CMS for _ the CP-67 SAVESYS 
function. 


OPERATIONAL PROCEDURES 


The device on which the shared systems residence volume 
exists must be ATTACHed to the CP-67 system to be made 
available to all potential users. Those users with 
appropriate directory entries will be given read-only access 
to the volume. Write access to the volume will be given if 
the directory entry so indicates, or if the real device 
containing the shared system volume is ATTACHed to the 
user's virtual machine. For the latter, the real device 
must first be DETACHed from the system. 


TUNING OF CP-6/7 


To prevent paging overload, CP-67 allows only a subset 
of the users to be eligible for dispatching at one time. 
There are two queues for such users; Q1 and Q2. A user will 
be dropped from a queue after using an allotted amount of 
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computer time (400 milliseconds for 01, 5 seconds for 02) or 
when CP-67 determines that the user is in wait state with no 
I/O outstanding for a high-speed device. A user enters Q1 
whenever there is an I/0 interrupt from the virtual 
operator's console or a virtual 270x line. If a user uses 
his allocated time in Q1, he is dropped from Q1 and 
scheduled for Q2. All 1 users are serviced in a 
round-robin fashion before Q2 users. Q2 users are serviced 
according to their priority and operating characteristics. A 
user's priority is defined in the CP directory and can be 
examined by ‘QUERY PRIORITY once the user has’ logged in. 
The priority of a logged in user can be changed by ‘SET 
PRIORITY userid nn‘. It 1S recommended that all users of 
Similar characteristics (i.e., running CMS) have the same or 
Similar priority. Only certain users (i.e. high priority 
processing users or users not requiring average service) 
should have their priorities set higher or lower (smaller or 
larger number) respectively. 


The number of concurrent Q1 users is limited to a 
maximum fixed number. In general we have found the maximum 
to be greater than any number actually achieved. 


The number of concurrent Q2 users is limited by the 
paging activity of the system. A ‘paging cost‘ value is 
calculated for each user, which is proportional to the 
paging activity caused by that user divided by the Q2 
(paging activity control) value. A Q2 user is' allowed to 
enter the queve if his ‘paging cost‘ value plus the sum of 
all ‘paging cost‘ values for users currently in both Q1 and 
Q2 ais less than a system maximum. The Q2 value has a 
default of 14 and can be interrogated and changed froma 
class A ID via the ‘QUERY Q2 and ‘SET Q2* commands. A 
decrease or increase in the value of Q2 causes a 
corresponding decrease or increase in the paging activity of 
the system. The maximum range for the Q2 value is from 5 to 
25; the recommended range is from 8 to 16. 


The paging algorithm is tied to this dispatching 
system. Whenever a page of memory is required, PAGTRANS 
selects a non-referenced page. The intent of this queue 
structure is to set a limit on the number of tasks that can 
compete for computer resources (memory and cpu), and to 
segregate short execution tasks (for example, edit requests) 
From long execution tasks (for example, FORTRAN 
compilation). By so segregating the tasks, limiting the 
number of long execution tasks, and minimizing paging 
between runnable users, excessive paging can be avoided. 


The queue sizes are automatically adjusted at system 
IPL time based upon real core size. The queue values for 








various core capacities are 


256K 512K 768K 1024K 1280K 1536K 1792K 2048K 
O1 3 6 9 12 15 18 21 24 
QO2 = 14 for all sizes 


Note that the Q1 value is the maximum number of users in Q1 
at any given time, while the Q2 value is a paging activity 
tuning value. The number of users in Q2 at any given time 
is computed dynamically and thus varies as a_ function of 
system load. 


The operator has a console function to change the amount of 
system paging activity by altering the Q2 value as described 
above. 





OBTAINING CP-67 DUMPS -- VDUMP, FDUMP, EDITDUMP 


Note: The VDUMP EXEC procedure invokes the FDUMP and 
EDITDUMP modules that produce formatted CP-67 abend dumps 
from the disk dump for the user specified to receive the 
dump (SYSDUMP= in the SYSGEN macro). 


The VDUMP program runs under the control of the 
Cambridge Monitor System. It is used to retrieve CP-67 
dumps from disk after an ABEND in the CP supervisor. When a 
system crash occurs, a spool file is created for the virtual 
machine whose USERID is specified in the SYSGEN macro of 
RIOxxx as the SYSDUMP parameter. The spool file then may be 
printed as a CP-67 system dump by issuing the CMS command 
VDUMP to the designated virtual machine (see section on 
AUTODUMP and RE-IPL). 


In order to create the CMS command called VDUMP on the 
appropriate virtual machine, this procedure may be followed: 
a. Read the punched card deck for VDUMP EXEC, FDUMP TEXT, 
and EDITDUMP TEXT into the appropriate virtual machine 
(attach a USERID card to the front of the deck). 

b. IPL CMS 

Cc. offline read * 

d. load FDUMP 

e. genmod FDUMP 

is load EDITDUMP 

du. genmod EDITDUMP 

The virtual machine which has access to the system dump 
created by the autodump feature must have the standard CMS 
virtual device addresses. In addition, this machine must 
contain the following directory entry for a special virtual 
device which reads the spooled file for the dump: 


UNIT OF1,RPRT 


To print a dump, type the CMS command VDUMP. The system 
will respond with: 


WHEN PROMPTED REPLY YES TO PRINT DUMP, NO TO IGNORE AND ERASE 


CAUSE OF SYSTEM DUMP: 
‘cause" AT LOCATION xxxxxx REPLY YES OR NO 


ace): aaa 


where cause is SVC 0, PROGRAM CHECK, MACHINE CHECK or 
UNKNOWN CAUSE. 


The following error messages may be encountered: 


I/O ERROR READING WIDE CARD 
A permanent I/0 error on the CP-67 spooling file has been 
encountered. 


FIRST WIDE CARD NOT LOW CORE RECORD 
The first spool file record did not correspond to the format 
expected. 


READER EMPTY 
No spool file exists in the “spool file reader" at address 
OF1. 


I/O ERROR WRITING TO DISK. TRY AGAIN. 
A permanent error was encountered in writing the dump to the 
CMS disk. 


When the dump is finished, the message END OF DUMP is 
printed at the terminal and control returns to CMS. 


The VDUMP printed output is preceded by a header page 
giving the date and time of system crash 


CP-67 SYSTEM ABEND DATE mm dd yy TIME hh mm ss'- cause AT LOC xxx 


The following are printed in the edited part of the dump: 


~ The general purpose registers, the control registers, 
the CSW and CAW 


- The interrupt code, old and new PSW's 


- General register analysis, the contents of all 16 
general purpose registers followed by the name and the 
displacement into the routine if the register contains 
an address 


- A listing of CP-67 nucleus routines and their entry 
points from CPSYM 


- An edited display of the multiplexor real device 
control blocks. The address, name of the block and its 
contents are printed. 


- An edited display of the real channel, control unit 
and device blocks, indented to indicate attachment. 
Should an IOTASK have been active at the time of the 
system dump, it is printed after the block to which it 
waS pointing. 
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= Control block associated with each virtual machine. 
The address and contents of the UTABLE, the MVDEBLOK 
and the virtual channel, control unit and device blocks 
attached to the virtual machine are printed. 


If the default (CP) is in effect for the SET DUMP 
command, or if CP is specified as an option, the following 
is printed in the dump: general-purpose registers 0-15, 
control registers 0-15, and allof CP nucleus and free 
storage. If ALL is specified aS an option, the dump 
includes all of real core. | | 


CP-67_ EXEC PROCEDURES 


The following CMS EXEC procedures are distributed with 
the CP-67 system. These procedures should be used to 


_ generate and maintain the system. 


CPASMGEN 


CPASMGEN 61 


This EXEC procedure is the one used to completely assemble 
the CP-67 system producing a printed listing and a LISTING 
tape. An auxiliary EXEC procedure with an ordered list of 
all SYSIN is necessary for complete generation. For 
instance, if CPLIST EXEC consists of the following: 


§1 62 ACCTON 
6&1 62 ACNTOFF 
61 6&2 ACNTIME 
etc. 


then the following CMS procedure assembles all the modules 


in CPLIST EXEC: 


CPLIST EXEC CPASMGEN 


CPGEN 
CPGEN &1 &2 


CPGEN is used to punch a self-loading CP nucleus, the CP 
utilities, and CP loaders. 


E1 = 000] 010 | 030 | 040 | OOF | OOF 
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Select the correct relocating loader for the 
installation, where the three characters indicate the 
system's printer address. 


62 = The name of the installation's real I/O configuration 
deck, for example, RIOCSC. 


CPLIST 
CPLIST 6&1 


This EXEC procedure prints one or all files from a CP-67 
LISTING tape generated by the CPASMGEN EXEC procedure. The 
first file on the listing tape must be a CPLIST EXEC file. 
The CPLIST EXEC file is merely a sequential list of the 
names of the LISTINGS that follow. For example, see CPLIST 
EXEC. If 611s ALL then all files are printed, otherwise 
the tape is searched for the desired file (for example, 
DISPATCH) and that file (DISPATCH LISTING) is printed. 


CPMACADD 

CPMACADD 6&1 6&2 

CPMACADD adds file 6&2 (either ASP360 or COPY) to MACLIB 
named 61. The MACLIB must already exist and the ASP360 or 
COPY file should be updated before adding the file. 

CPMACGEN 

CPMACGEN 6&1 

CPMACGEN creates a MACLIB, named 6&1 MACLIB, from all COPY 
and ASP360 files on the P-disk. The COPY and ASP360 files 
should be updated using CPUPMAC before using this command. 
CPMACREP 

CPMACREP 6&1 6&2 

CPMACREP replaces the file &2 (COPY or ASP360) in the MACLIB 
named 61. The MACLIB must already exist and the ASP360 or 
COPY file should be updated before replacement. 

Note. The ASP360 file may contain more than one MACRO 
definition. If one macro is changed the entire file 
(ASP360) must be added or replaced, not the macro name. 


CPPTF 


CPPTF EXEC is used for CP-67 maintenance. For a description 


Of CPPTF EXEC, see "CP-67 Maintenance Procedure." 


CPPUNCH 
-CPPUNCH 6&1 &2 


Thes EXEC procedure is used by the CPSYS EXEC function in 
the CPGEN procedure. Its function is to select either the 
.§1 TEXT file if it exists or the &1 TEXT file. If neither 
exists, an error message is printed. 


Note: CPPUNCH, CPSYS, and CPTGEN use .&1 TEXT in preference 
to to €1 TEXT. 


CPSYS 
CPSYS 


This EXEC procedure is used by the CPGEN EXEC function to 
produce the CP-67 load deck. It contains control statements 
and an ordered list of the nucleus components. 


CPTGEN 
CPTGEN 6&1 &2 


This EXEC procedure is used only when running under CP-67, 
since it uses the XFER function. Its purpose is to create 
an IPL"*able tape for CP-67 disk loading. The 6&1 is the name 
of the desired loader for the printer (for example, RELDROOE 
or RELDRO30). The 62 is the name of realio configuration 
module (for example, RIOCSC). This EXEC procedure uses the 
CPSYS EXEC procedure to produce a load deck. A tape must be 
attached as 181 and a file called TAPE LOAD is read onto the 
user's P-disk. The reader is PURGED for this operation. 
The EXEC procedure then writes the TAPE LOAD file on tape. 


CPUPASM 


CPUPASM 61 6&2 


CPUPASM is used to update a SYSIN file with an UPDATE file, 
if it exists, and to assemble the updated file or the 
original if no UPDATE file exists. €1 is the name of the 
SYSIN file to be processed. 6&2 can be NODECK if no TEXT 
file is to be produced. The original SYSIN and UPDATE files 
remain. The TEXT file created is for the updated version 
and is named 6&1 TEXT if no UPDATE file is applied, or .&1 
TEXT if an UPDATE was applied | leaving the original &1 TEXT. 
No LISTING file is produced. 


~ 42 - 


CPUPMAC 
CPUPMAC 6&1 


CPUPMAC updates a &1 MASTER file if it exists, and produces 
a &1 COPY or a &1 ASP360 file. If a 6&1 MASTER file does not 
exist, CPUPMAC updates an 61 COPY or 6&1 ASP360 file with 6&1 
UPDATE, Saving the old file as 61 MASTER and creating the 
updated file as 61 COPY or 6&1 ASP360. There must be an &1 
UPDATE file on the users disk, aS well as a &1 COPY or 6&1 
ASP360 file. 

Note. This command must be used on all ASP360 or COPY files 
which have updates, before using CPMACGEN. 


Hint. Instead of regenerating CPMACS MACLIB every time an 
ASP360 or COPY module is changed, it is more convenient to 
create anew MACLIB called MACUP MACLIB. The assemble 
procedures automatically access MACUP before accessing 
CPMACS. 





LDRG 
LDRG 


This EXEC procedure punches the LOADER and TEXT decks 
required to generate a LOADER. The six files form an 
IPLable program that will produce an IPLable LOADER. The 
installation may choose to make modifications to the RELDR 
SYSIN for certain reasons. The assembled module (RELDR 
TEXT) is then used by the LDRG EXEC to produce a new LOADER. 


VDUMP 
VDUMP 
This EXEC procedure invokes the FDUMP and EDITDUMP modules 
that produce formatted CP-67 abend dumps from the disk dump 


for the user specified to receive the dump (SYSDUMP= in 
SYSGEN macro). 


CP-67 DECK FORMATS | 

This section describes the format of the CP load deck 
and the utilities. The name Of each deck and its 
serialization in columns 73-76 are specified. | 


CP-67 SYSTEM 


The following text files are contained in the CP load 
deck: , 
Module Serial 


Relocating Loader (RELDRxxx) 
SLC 000080 loader control card--with PSA 
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PSA PSA 

ACCTON ACON 
ACNTOFF ACOF 
ACNTIME ACNT 
CCWTRANS CCW 

CFSCOM CCOM 
CFS DBG CDBG 
CFSIPL CIPL 
CFS MAIN MAIN 
CFSPRV CPRV_ 
CFS ORY CORY 
CFSSET CSET 
CFSSPL CSPL 
CFSTACH TACH 
CHKCUACT  CKCU 
CONSINT CINT 
CONVRT CVT 
CPCORE CPC 

CPFILE CPF 

CPSTACK CPK 

CPSYM CPSM 
DEDICATE DED 

DIAGDSK DGIO 
DIAL DIA 

DIS PATCH DISP 
DSKDUMP DSKD 
EXTEND XTND 
FREE FREE 
IOINT IOI 

IOERROR IERR 
LINK LINK 
LOGON LOG 

LOGFILES LGFL 
MRIOEXEC MRIO 
MVIOEXEC MV IO 
PACK PACK 
PAGTR PGTR 
PAGTRANS PAGE 
PAGEGET PGET 


PRIVLGED 
PROGINT 
QUEVIO 
RDCONS 
RDSCAN 
RECFREE 
RESINT 
RIOxxx 
SCANUNIT 
SCHEDULE 
STCONSIO 
SYSDESCR 
TMP SPACE 
TRACER 
UNSTIO 
UNT RANS 
USERLKP 
USEROFF 
VIOEXEC 
VSERCH 
WRTCONS 


IcS CPEND 
SLC 020000 


IPL 


SLC 020800 
CPLOCS CPLC 
SLC 021000 


SYSTEM 


SLC 022000 


CHKPT 


SLC 023000 


CPINIT 


SLC 025000 


SAVECP 


LDT SAVENUC 


CP UTILITIES 


Module 


BUZZARD 
DIRECT 
FORMAT 
SAVESYS 
VDU MP 
FDUMP 
EDITDUMP 
MINIDASD 
CPDMPRST 
SAVEOS 
CPIPL 


PRIV 
PROG 
QUEV 
RDCN 
RDS 
REC 
RST 
RIO 
SUN 
SCHD 
SCN 
SDCR 
TMP 
TRAC 
UNS 
UNTR 
ULKP 
USE 

VI OX 
VSS 
WCN 
loader 
loader 
IPL 
loader 


loader 
SYS 
loader 
CHKP 
loader 
CPI 
loader 
SCP 
loader 


Serial 


BUZ 

DIR 

FOR 

SSYS 
VDMP 
FDMP 
EDMP 
MDSD 
CPDM 
SVOS 
CIPL 


control 
control 


control 
control 
control 
control 
control 


control 


The following files are the CP utilities: 


card--with 
card--with 


card--with 
card--with 
card--with 
card--with 
card--with 


card 


IPL TEXT 
IPL TEXT 


CPLOCS TEXT 


SYSTEM TEXT 


CHKPT TEXT 


CPINIT TEXT 


SAVECP TEXT 


CP-67 MAINTENANCE PROCEDURE 


When corrections have to be made to a CP<67 module, a 
PTF is made available to the installation through the normal 
channels. The PTF is in a form suitable for a CMS OFFLINE 
READ or TAPE LOAD function depending upon the distribution 
medium. A special EXEC procedure is distributed to be used 
when applying PIF‘s. A description of the use and function 
of this procedure is given below. 


CPPTF EXEC 
CPPTF 6&1 6&2 


where &1 is the name of the CP-67 module to receive the 
PTF and &2is the PTF number (for example, CPPTF 
DISPATCH A32486CA). Having first loaded the PTF on to 
the maintenance P-disk (using OFFLINE READ or TAPE 
LOAD) the user then issues all necessary CPPTF EXEC 
procedures to effect the change. One PTF may involve 
changes to several modules. For instance, PTF number 
A32486CA may create (through loading on to the P-disk) 
the following files: 


DISPATCH A32486CA 
PAGTRANS A32486CA 
- UNSTIO A32486CA 


The user must then issue the following CMS commands: 


CPPTF DISPATCH A32486CA 
CPPTF PAGTRANS A32486CA 
CPPTF UNSTIO A32486CA 


The function of the CPPTF is as follows: 


The PTF file (for example, DISPATCH A32486CA) is 
applied to the corresponding SYSIN file (that is, 
DISPATCH SYSIN), using the CMS UPDATE program. The 
PTF creates a new SYSIN file replacing the original. 
If the installation wishes to preserve the original 
SYSIN file, it should be saved beforehand or copied 
and given anew name. Once the new SYSIN has been 
created, it should remain on the disk (or be 
available) since further PTF"'s that may be applied to 
the module may require that a previous PTF be applied 
first. The CPUPASM EXEC procedure is then invoked to 
assemble the new SYSIN file. If the installation has 
its own UPDATE file, CPUPASM applies it to the now 
modified SYSIN. The installation should check that 
any UPDATE file interfaces correctly to the SYSIN 
file once PTF's have been applied. The CPPTF EXEC 
procedure finally punches the &1 TEXT file, prints a 
completion message, and exits. 
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CP-67 TRACE FACILITIES 


The SET TRACE console function initiates and terminates 
the following tracing functions: user interrupts, 
instructions including interrupts and successful branches, 
I/O operations issued to a selector or dedicated device, and 
virtual and real CCW's involved ina selector or dedicated 
device I/O operation. Output can be directed to either the 
virtual console or printer, or both. Tracing of successful 
branches and/or all instructions involves considerable 
overhead and should, therefore, be used wisely, especially 
when output only to the virtual printer. (Note: The TRACE 
options BR (to trace all successful branches) and ALL (to 
trace all instructions) can be issued only by a class A or B 
user.) The virtual printer will enter console function mode 
after any output message directed to it; it is necessary to 
issue a ‘begin* to continue execution. When tracing on the 
Virtual printer, the printer must be closed (i.e., ‘close 
00e') to get output after turning trace off. Note: The 
TRACE (6) option must be chosen at system generation time in 
order to issue SET TRACE. 





SET ADSTOP enables the user to specify a virtual 
instruction address at which execution is to be stopped. 
Only an instruction execution address stop can be 
detected--not a storage reference. The user is placed in 
console function mode; a ‘begin"* will resume execution from 
the address stop location. The address stop function is 
removed by a) reaching the address stop location, b) ‘ipl' 
or ‘reset* of the virtual machine, or c) the set adstop off 
command. Note: the user must have the TRACE(6) option at 
system generation time in order to issue SET ADSTOP. 


See the CP-67/CMS User's Guide and CP-67 Operator's 


Guide for further information. 


SECTION 2: INSTALLING CMS 
DUMP/RESTORE UTILITY 


To create aCMS System disk, place the distribution 
tape on a tape drive, address OCUU. Clear core and IPL the 
tape by pressing the LOAD button. When the wait light 
remains on, and the system and load lights go off, hit 
REQUEST on the online console. DUMP/RESTORE is’ given 
control. 


CMS may be restored under CP-67, if CP already exists. 
Merely, attach the CMS System Disk tape to a virtual machine 
and issue IPL cuu. Produce an ATTENTION interrupt. 


The console address is dynamically set. If replies are 
incorrect while the DUMP/RESTORE is executing, DMPRST 
reinitializes itself and repeats Question 1. If an fI/0 
error is sensed on the disk or tape, it tries to rectify the 
error condition. If successful, it continues. If not, it 
prints out a message and terminates. 


Termination, either after a successful operation or 
because of an error, places the CPU in the wait state. 


Ql: TASK? ("DUMP™ , “REST"™): 
DUMP-~disk to tape 
RESTORE--tape to disk 


Q2: DEVICE TYPE? ("2311" , %2314"): 
specify the disk device type 


O3: TAPE ADDRESS? ("OCUU"): 
self-explanatory. Must enter a four digit 
hexadecimal reply (for example, 0181, 
0275) 


O4: DISK ADDRESS? (“*0CUU"): 
self-explanatory. The reply must be four 
hexadecimal digits (for example, 0191,0290). 


REWIND TAPE? ("YES" , “NO"™): 

This applies to before and after the operation. 
Obviously, since the tape after IPL is positioned at 
its second file, the answer must be NO. 


Q5 
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Q6: NUMBER OF CYLINDERS? ("ONNN"): 
self-explanatory. The reply must be four decimal 
digits (for example, 0203, 0100). For restoring the 
distribution tape, specify 203 cylinders for a 2311 
or 54 cylinders on a 2314. 


QO7: STARTING CYLINDER? ("ONNN"): 
self-explanatory. (For the system disk, reply: 
"0000". ) 


O8: BEGINNING OF TAPE? (“‘YES™ , “NO™): 
The answer determines if a tape mark is to be written 
ahead of the file. If YES, a tape mark is written; if 
NO, the EOF at the end of the previous file serves as 
the tape mark for the beginning of this file. (When 
restoring the distribution tape, 08 is not asked.) 


The DUMP/RESTORE operation begins after the last 
question iS answered. If either device is not ready, the 
program waits for its ready state. When restoring, the disk 
need not be formatted or DASDI‘ed. DMPRST formats the disk 
aS it is being restored. 


Upon encountering an EOF, satisfying the amount of 
cylinders specified in 06, or executing a SEEK beyond the 
disk limits, the operation terminates with the message 


*‘DUMP/RESTORE MOVED nnn CYLINDERS 
THERE WERE nnn RECOVERABLE TAPE ERRORS.‘ 


TASK? ("DUMP",“REST"): restore 

DEVICE TYPE? ("2311","2314"): 2314 

TAPE ADDRESS? ("0CUU"): 0181 

DISK ADDRESS? ("0CUU") : 0190 

REWIND TAPE? ("YES","NO"): no 

NUMBER OF CYLINDERS? ("ONNN"): 0054 
STARTING CYLINDER? ("ONNN"): 0000 
BEGINNING OF TAPE? ("YES","NO"): no 
DUMP/RESTORE MOVED 054 CYLINDERS. 
THERE WERE 001 RECOVERABLE TAPE ERRORS. 
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Figure 1, Restore procedure for CMS distribution tape 
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CMS SYSTEM DISK 


Once restored, _ the CMS System disk 
following appearance: | *  @., 


Block Information 


0-2 IPL pointers, CCW'S, etc. 
3 ited = ——-CMS190 

4 Master File Directory 
5-7979 


assumes the 


1. Nucleus Text decks in one file called NUCLEUS 3.1, in 
which each individual text deck is preceded by an 
OFFLINE READ filename TEXT card. The nucleus text decks 


are also present individually. 
2. Disk Command MODULE files. 
3. Disk Command TEXT files. 
4. EXEC Procedures | 
5. MACLIB and TXTLIB files 


7980-8100 


IPL‘able Nucleus (0-12000x and loader tables). 


The nucleus routine, NUCON, contains a device table. It 


has been initialized as follows: 


CONSOLE (CON1) = 0009 
CREADR (RDR1) = 000c 
PRINTER (PRN1) = OOOE 
CPUNCH (PCH1) = 000D 
S-Disk (DSK1) = 0190 
P~Disk (DSK2) = 0191 
T-Disk (DSK3) © = 0192 
A-Disk (DSK4) = 0000 
B-Disk (DSK5) = 0000 | 
C-Disk (DSK6) = 019C 
TAP1 (TAP1) = 0180 
TAP2 (TAP2) = 0181 . 
CRT1 (CRT1) = 0106 — 
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These values are the standard CMS machine device addresses. 
If it is necessary to redefine these device addresses when 
running CMS on the _ physical machine, refer to “Bare 
Machine-CMS". 


The second file on the Source Disk Tape contains an 
alphabetized TAPE DUMP of the ‘standard' CMS System Disk. 
This is included so that existing users may selectively 
acquire TEXT and MODULES by using their current system. 


BARE MACHINE-CMS 


Having RESTORE'd the CMS System disk onto either a 2311 
or a 2314 disk pack, CMS may now be executed. Set the 
address of the System pack into the LOAD unit dials and 
depress the LOAD button. When the CPU enters the wait state, 
hit the REQUEST button on the operator's’ console. The 
INITB67 routine 1S given control. Note that in looking for 
the 1052 online console on the real machine, CMS looks for 
device 009 or O01F before waiting on first interrupt denoting 
the console; on the virtual machine CMS only looks’ for 
device 009 as the console and does not wait for an 
interrupt. 


Since the physical device addresses of your particular 
installation might not be identical to CMS standard virtual 
device addresses, CMS allows redefinition of the device 
table, so that bare machine operation of CMS is possible. 


QO1: REDEFINE DEVICE ADDRESSES? ("YES","NO") .. « 
NO--CMS assumes the standard addresses 
YES--address modification is made 

C1: ALL DEVICE ADDRESSES MUST BE ENTERED AS 4 
HEXADECIMAL DIGITS: “Ocuu". 

03: OPERATOR'S TERMINAL... 


After redefining addresses, CMS types the following 
identification message: 
CMS .. VERSION n LEVEL m 


where n is the version and m the modification number. 


CMS SOURCE DISK 


On the CMS Source Disk tape, which is one of the three 


Basic Program Material tapes, is a TAPE DUMP of the file 


SOURCE EXEC which is an alphabetized log of the source files 
distributed. After restoring the CMS System disk, issue TAPE 
LOAD to obtain the SOURCE.1 EXEC file; a second TAPE LOAD 


command will load the Source files (SYSIN files for all of 


CMS, excluding OS/360 language processors and libraries, 
plus EXEC files). However, TAPE LOAD is acCMS command. 
Therefore, the loading must be executed under CMS control. 


Once CMS iS operational, obtain a P-disk of 203 2311 


cylinders or 54 2314 cylinders, format the disk (FORMAT P 
ALL), and load the tape (TAPE LOAD). The tape must be 
mounted on symbolic device TAP2. 


Files 3 - 9 on the Basic Source Tape contain an 
alphabetized TAPE DUMP of all OS language processor object 
decks which are contained in CMS Version 3 Level 1: 
ASSEMBLER-F, Rel.20, Component ITEU; FORTRAN-G, Rel.20, 
Component IEY; FORTRAN-G, Rel.20, Component IHC; PL/I, 
Rel.20, Component IEM; PL/I, Rel.20, Component IHE. 


ALTERING THE CMS SYSTEM DISK 


NUCLEUS 


After restoring the CMS System Disk, IPL 190. Use the 
CMS System Disk as a P-Disk by issuing LOGIN 190 P. 


The LOADER deck supplied for Nucleus Generation is used 
to IPL the nucleus under CP (that is, it recognizes the 
standard CMS virtual device addresses, PRINTER = X‘'OOE'). If 
the nucleus is to be IPL‘ed on incompatible device 
addresses, the loader deck (first deck) must be replaced 
with the appropriately addressed loader, located on the CP 


distribution tape. Several loaders for different printer 


addresses are available from the CP distribution tape. 


The CMS nucleus may be created by using the two EXEC 
procedures on the system disk--PUNCH and NUCLEUS. Issue the 
command NUCLEUS EXEC PUNCH userid/OFF. Each component text 


deck of the nucleus is punched. If a userid was specified, 


the deck is xXFER‘ed to that userid. If OFF was specified, 
the physical card deck is punched. 
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IPL*‘ABLE SYSTEM DISK 


To rewrite the IPL‘able nucleus onto the CMS System 
disk, place the nucleus in the card reader and press the 
LOAD button. Under CP, read the nucleus deck into the CP 
card reader with the appropriate ID card, or use the EXEC 
procedure NUCLEUS and XFER the deck into the card reader, 
then type the CP command IPL 00C. The nucleus is loaded 
into core, linkages and V-cons are resolved, and a load map 
is produced. An IPL‘able core-image copy of the nucleus 
(locations 0-12000) may now be written onto disk. 


After the IPL sequence has completed, the INITIPL 
routine is given control. It expects the standard console 
(terminal) address (009) or (01F) on the real machine. If 
it is other than 009 or O1F, the wait state is entered, and 
INITIPL accepts an ATTENTION interrupt in order to define 
the console address. The following information is 
requested: 


"REWRITE NUCLEUS? (YES,NO)"™: 
YES--a new IPL‘able copy of the CMS nucleus is to be 
written onto disk 
NO --no writing takes place. Control returns to INIT 
(CMS initialization routine) 


"SYSTEM DISK? (0CUU,SYS)": 
The S-Disk slot in the NUCON Device Table must 
contain the address of the device to be used as the 
CMS System Disk. If the reply is “"O0CUU", the S-disk 
address will be set to ‘*0OCUU". If "SYS" is entered, 
the default value (X‘'190') will be used. 


"IPL DEVICE? (0QCUU,SYS)": 
A core-image copy iS written onto device OCUU (if 
specified) or onto SYS, which is the System disk 
address specified in the nucleus device table. 


“STARTING CYLINDER? (ONNN,SYS)": 
The $core~image copy is placed at cylinder 
ONNN--decimal representation--or on the SYS cylinder. 
The SYS cylinder is 
cc hh rr _ biock 
2314: 53 O4 00 7980 
2311: 199 05 00 7980 


-~ 53 - 


“VERSION IDENTIFICATION (30 reeset | : 
Thirty bytes of information, including planks, are 
used as the version title and are printed out when 
IPL*‘ing the CMS nucleus. | 


"INSTALLATION HEADING... (40 CHARACTERS) ": 
Forty bytes of information, including blanks, are 
used as an installation heading at the top of printer 
output. 


An IPL*‘able copy of the CMS nucleus (locations 0-12000) is 
written onto the specified disk. A numerically ordered load 
map showing all deck names and reference points for the 
nucleus is written to the system printer device. There are 
three unresolved symbols at the end of the load map, as 


follows: 


BATCH, SYSCTL--external references for the Batch 
Nucleus. 


CNIRL--unresolved simulation routine. 
SAVING CMS UNDER CP 


In place of IPL'‘ing a device each time CMS is to be 
invoked, CP allows the system programmer to SAVE a copy of 
the CMS nucleus, so that a user may invoke CMS by issuing 
the CP command IPL CMS. | 


To save CMS, IPL the CMS System disk on the bare 
machine (that is, not under CP). Cause an ATTENTION 
interrupt on the console. | 


The following is typed: 


Q1: REDEFINE DEVICE ADDRESSES? ("YES","NO")... (reply NO). 


This question is asked when running CMS on the bare 
machine to allow the user to dynamically change the 
standard device addresses. 


Q2: WILL THE CP-SAVE FUNCTION FOR CMS BE EXECUTED? 
("YES","NO")... (reply YES). | 


C1: ALL DEVICE ADDRESSES MUST BE ENTERED AS 4 HEXADECIMAL 


DIGITS: “O0CUU". 
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QO3: ENTER THE “REAL™ address of the CMS SYSTEM DISK... 
reply “OCUU", where CUU is the real online address of 
the CMS system disk--as opposed to virtual address 
190. 


Q4: SET THE “ADDRESS COMPARE™ SWITCH FOR LOC X‘88'‘'; REPLY 
"GO" After setting the instruction counter switches to 
reflect hexadecimal location ‘88°, and setting the 
“address compare™ key “on™, reply “GO". 


C2: WHEN “MANUAL"™ STATE IS ENTERED, IPL THE CP “SAVESYS" 
UTILITY DECK FROM THE CARD READER 


When the CPU stops at location X‘'88‘', place the CP SAVESYS 
utility deck with loader and control card into the real card 
reader, reset the load address on the CPU console, and IPL 
the card reader. The message NORMAL TERMINATION OF SAVE 
FUNCTION is typed. 


CMS may also be saved on a virtual machine. However, it is 
advised that only a system programmer well-versed in the 
concepts of CP/CMS attempt the following: 


- Logon as any virtual user. While still in the CP 
environment issue these two commands: 

1. DETACH OFF 
First the software timer device must _ be 
detached from the virtual machine because CMS 
must ‘think’ that it is executing on the real 
machine. 

2. LINK sysuser cuu 230 w 
(a password probably is also necessary). 
Write status must be acquired for the CP 
system disk (cuu) which will contain the 
"saved* CMS nucleus. It must be virtually 
attached at address K‘'230', which matches the 
address specified in the data card for the 
SAVESYS program. 

3. Verify that an IPLable copy of the CP SAVESYS 
program is in the virtual card reader. A copy 
of that program resides on the CMS S-Disk as 
SAVECMS LOAD P1 and can be obtained when the 
S-Disk is accessed as a P-Disk. 


. IPL 190 This loads into core the CMS nucleus. The 
machine will enter wait state. 


. Produce an attention interrupt to define the console 


address. Answer questions 1 and 2 as above. 
Question 3 must be answered with the virtual address 
of the CMS system disk, 190. 


Now the tricky part: for question 4, reply as 


follows-- 


(NOTE: The following procedure can be bypassed 


by using CP's SET ADSTOP xxxxx command, where xxxxx | 


equals 88, if the &TRACE option is selected for that 


Virtual machine.) 


GO (type a blank,then hit ATTN, entering CP 
environment) | | 


When CP environment is entered, issue the following 
commands: i | 
1. 4d 88 | 
88 = 070058C0 
Ze ST 88 47F00088 
3. begin 


CMS will type C2 as above. Note, no CPU panel 
manipulation is necessary or for that matter 
possible. The hard address stop is achieved by 
causing a single instruction loop at location X"88"'. 
Wait about 10 real seconds. 


Hit ATTN and re-enter CP environment. 

1. d PSW 

PSW = xx xXx xxxx xx000088 

(if the PSW is another value, enter begin and wait 
another 10 seconds before hitting ATTN) 

2. ST 88 070058C0 

3. IPLSAVE 0O0C 

NORMAL TERMINATION OF SAVE FUNCTION 


Logout of CP and login again to reacquire the timer 
device, OFF, and IPL CMS. Note the form of the 
IPLSAVE console function issued in step 3. IPLSAVE 
preserves virtual memory; whereas, IPL clears 
virtual memory prior to executing. 


CMS EXEC PROCEDURES 


~The following EXEC procedures can be used in the building 


and maintaining of the CMS system. 


ASMGEND, FORGEND, PLIGEND 


ASMGEND/FORGEND/PLIGEND 
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Used to create overlay structures for the OS language 
processors, using the object decks and producing modules. 
These -GEND EXEC procedures are used only when creating the 
overlay module structure. Do not try to use them when the 
text decks of the processor components are not present. For 
re-genmoding the interface modules, use CMSGEND EXEC. No 
arguments are passed to these -GEND procedures. ASMGEND, 
FORGEND, and PLIGEND reside on the source disk. 


CMSGEND 
CMSGEND 61 
Creates any or all CMS disk-resident modules. The name of 
the disk module to be created must be passed to CMSGEND (for 
example, to create the TAPE module, issue the command 
CMSGEND TAPE). CMSGEND resides on the CMS’ system disk and 
can only be accessed when the S-disk is used as the P-disk. 
An example of CMSGEND EXEC follows: 

CMSGEND &1 6&2 


where 61 = module name (= START card name) 


&2 


TEXT name ( if 62 is present) 
If the START card name and TEXT name are the same, the 
command 1S CMSGEND &1 00. If the START card name and TEXT 
deck name are different, the command line is: 

CMSGEND (START name) (TEXT name) 
Example: 


CMSGEND COMBINE 00 


will produce a COMBINE module with a mode of 'P2‘. 


CMS PTF 

CMSPTF 6&1 62 

Will permanently apply a ‘PTF‘ to a_ source deck, print a 
LISTING to the offline printer, and punch off a TEXT deck. 
The command line is: CMSPTF 61 62 , where 61=filename of 
SYSIN and &2=filetype of PTF deck, i.e. ‘AxxxxyCA'. 

CMSSORT 


CMSSORT ‘fn ‘ft' P 


will produce a sorted file of the P<disk. 


Will list and sort in alphabetical order into a file the 
names of the files on the disk for which the MODE letter was 
given. The file will be printed on the offline printer. 


CMSUPASM 


CMSUPASM &1 &2 


where 61 = SYSIN name, and &2 = UPDATE name. 


CMSUPASM is used to update a source deck and get a copy of 
the new object deck in a one-step procedure. This procedure 
will take the original source deck and the update deck and 
will create the new .SOURCE deck, assemble it producing a 
-TEXT deck, print a listing of the update changes, print an 
assembly listing on the offline printer, offline punch the 
-TEXT deck, and erase the .SOURCE and .TEXT decks. 


The options that can be used with CMSUPASM are: SP, NP, NPR, 
NDG, BLIP, and ORG, where SP = the .TEXT deck will be saved 
on the P-disk, NP = no offline punch of the .TEXT deck, NPR 
= no assembly listing on the offline printer, NDG = no 
online diagnostics, BLIP = use BLIP (BLIP character '?'), 
ORG = alter .XXX TEXT to original text name. Consider the 
following example of CMSUPASM EXEC: 


SOURCE DECK : TEST SYSIN 
UPDATE DECK : TEST UPDATE 


where the command is: CMSUPASM TEST SP, and the file results 
are: TEST SYSIN (original source deck), TEST UPDATE (update 
deck), and .TEST TEXT (new updated object deck). TEST 
UPDLOG and the Assembly listing are printed on the offline 
printer. 


NUCLEUS/PUNCH 


NUCLEUS EXEC PUNCH (userid, OFF) 


Used to create a physical CMS nucleus deck by punching each 
individual TEXT deck. Issue the command: NUCLEUS EXEC PUNCH 


userid, where userid is the identity of the virtual machine 


to which the nucleus deck is XFER'd. PUNCH EXEC will first 


search for an updated TEXT deck; i.e., when looking for 


INTSVC TEXT, it will first search for .INTSVC TEXT, then 
INTSVC TEXT. This will utilize a newly updated deck. 
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MAINTAINING THE CMS SYSTEM DISK 


To add or change commands in the nucleus or on the 
System disk, proceed as described below. 


CMS MAINTENANCE PROCEDURES 


To update the CMS system the procedure described below 
must be applied. 


When a PTF is received, the user should apply it to his 
SYSIN deck. The PTF is an update deck identified as 
"filename AxxxxyCA", where filename is the name of the 
routine to which the update is to be applied and AxxxxyCA is 
the filetype. xxxx iS the APAR number, and y is the APAR 
code that the PTF corrects. 


Example: 


v3 deck EDIT SYSIN 
Update EDIT AxxxxyCA 


The command to issue is UPDATE EDIT SYSIN EDIT 
AxxxxyCA (seq8 inc P) 


The “seq8" allows sequencing of up to eight digits. 
The “inc™ includes the sequence number of the update card 
into the new updated sysin file. The P causes a _ newly 
updated SYSIN file to be created. | 


The updated file created is EDIT SYSIN. 


Note. The original EDIT SYSIN is replaced with the updated 
copy. 


CMSPTF EXEC : 


The updating process described above can be executed 
with the aid of a CMS EXEC file called CMSPTF EXEC. 


This EXEC procedure takes the original SOURCE deck and 
the PTF deck and creates the new SOURCE deck, assembles it 
producing a TEXT deck, prints an UPDATE LOG of the update 
changes, and an assembly LISTING onto the offline printer, 
and offline punches the TEXT deck. The new SYSIN and TEXT 
decks remain on the user's read/write disk. 


This enables the user to update and get a copy of the 


new object deck ica euesetee procedure. 
 eMSPTF Apaanents and Options : 
The format of the CMSPTF command is as follows: 
CMSPTF filename filetype options 
where filename is the name of the SYSIN file to 


which the APAR is to be applied. 
filetype is the APAR identification 


OPTIONS defined: 


NP = No offline punch of the TEXT deck. 


NPR = No assembly listing on the offline printer. 
NDG = No diagnostic messages on the terminal. 
BLIP = Use BLIP, (BLIP Char. ‘ ? ‘) 


An example Of CMSPTF EXEC follows: 


SOURCE DECK : EDIT SYSIN 

UPDATE DECK ; EDIT AxxxxyCA 
Command : 

CMSPTF EDIT AxxxxyCA 
Results: 


The status of the files is as follows: 


EDIT SYSIN (updated source deck), EDIT AxxxxyCA 
(original PTF update deck), EDIT TEXT (new updated 
object deck); EDIT UPDLOG, and the Assembly 
listing are printed on the offline printer. 


CHANGING OR ADDING NUCLEUS RESIDENT COMMANDS 
Assemble the source of the new or changed command to 
obtain a loadable TEXT deck (object deck). 
If a new command, update and assemble the system 
routine FUNCTAB, making an entry into FUNCTAB for the new 


command. 


If a new command, replace the old FUNCTAB' text deck 
within the nucleus deck with the newly assembled copy. Also 
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add the text deck of the new command to the nucleus. 


If changing an existing command, replace the old TEXT 
deck with the newly assembled copy. 


If using the NUCLEUS/PUNCH procedure of creating a CMS 
nucleus, the newly updated TEXT decks need only be placed 
with the remaining TEXT decks. They will automatically be 
incorporated into the nucleus when it is constructed. 


Rewrite the CMS nucleus onto the system disk. 


CHANGING DISK-RESIDENT COMMANDS 


As above, obtain the object deck of the new command. 


Using the system disk as a read/write P-disk, offline 
read the text deck of the new command. 


The CMSGEND EXEC procedure may be used to generate any CMS 
disk-resident command distributed with the system. Details 
for generating each command can be determined by examining 
the CMSGEND EXEC file. 


MANAGEMENT OF TEXT FILES FOR LANGUAGE PROCESSORS 


On the Source Disk tape are the TEXT decks of all the 
processors distributed with the system. The following files 
are included in this tape, in the order indicated below and 
with the specified disk space requirements for loading: 


ASSEMBLER 211 CMS records 
FORTRAN Compiler 166 CMS records 
FORTRAN Library 213 CMS records 
PLI Compiler 1999 CMS records 
PLI Library 709 CMS records 


MODIFICATIONS TO PID TEXT DECKS FOR CMS 


For Assembler, Release 20, all IEUF/* TEXT decks”) are 
represented by one IEUF?7 TEXT deck, and all IEUF8* TEXT 
decks by one IEUF8 deck, as below: 


CMS original PID TEXT decks 


iP <a se — om <p oe ow mw coe co oe oe ce ee oe oe es a ee ee oe oe 


IEUF7 = TEUFTI 
IEUF/JE 
ITEUF 7D 
ITEUF7X 
ITEUF 7N 
ITEUF7V 
LTEUF 7G 
LEUFTC 


om eee eee eee ee eee eee eee eee eel eee ese 


IEUF8 = IEUF8I 
ITEUF8C 
IEUF 8M 
ITEUF8A 
LTEUF8P 
ITEUF8D 
ITEUF8S 
ITEUF8V 
IEUF8L 
ITEUF8N 


For FORTRAN, Release 20, the _ following decks have had their 
names changed: | | | 


PID Released Name CMS Renamed Deck 
LEYFORT IE YFORTO 
ITEYROL ITEYROL 3 
TEYINT ITEYINTS 


The CMS distributed IEYFORT TEXT deck contains the aera 
PID released text decks: 


CMS Name --> IEYFORTO IEYFORT1 IEYFORT2 IEYROL3 IEFYINTS4 
LTEYFORT = ------ ? 

PID Name --> IEYFORT IEYFORT1 IEYFORT2 IEYROL IEYINT 
For PL/I Release 20, the following decks have had REP cards inserted: 


PID Released Name Purpose 


ae ei ch CED ce au eee aE 46 eee cle CD Cm eD ae cE eo ome cu came come ce one ea 


LTEMAB To cause compiler to use 
dictionary blocksize as 
SYSUT1 file blocksize.. 
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IEMAS To provide an OS/360 save 
area for the ZINCLUDE function. 


Code has been added to module IEMAD to get the correct 
length of compiler modules for the DUMP option. 


C-DISK AS A READ-ONLY EXTENSION OF S-DISK 


The use of an extra disk as a read-only extension of the 
standard S-Disk is generally useful for one of several 
reasons: 


1. If the system customarily has a large number of users, 
it can provide a more efficient utilization of system 
resources to place some of the system disk programs and 
libraries on one disk pack, and others on another pack. 
If some of the programs and/or libraries currently on 
the S-Disk are placed on another disk instead, this can 
be accomplished. 


2a If a system disk gets very full from addition of new 
programs, it may be advisable to put new added programs 
on an extra disk instead of adding more cylinders to 
the S-Disk. 


3. It may be that certain new or restricted programs are 
to be made available to a limited number of users. In 
this case, such programs could be put onthe extra 
disk, which would only be in the directory of those 
permitted to use such programs. 


CMS has the capability to provide such an extra disk asa 
read-only extension of the S-Disk. This extra disk is the 
C-Disk, and has a default disk-address (in the NUCON table) 
of 019C. Be sure to place the cC-Disk as a read-only disk in 
the virtual machine description in the CP directory, with 
Virtual address 19C, for all users who are to have the 
C-Disk available to them. 


If the C-Disk is attached and ready at CMS Initialization 
time, while the version identification message is being 
typed, CMS automatically logs in the P2 files from the 
C~Disk, as a read-only extension of the S-Disk, in a manner 
Similar to the SYSGEN function for obtaining the SSTAT table 
from the S-Disk. | 


The cC-Disk is then a_ read-only extension of the S-Disk, 
transparent to most CMS commands. STAT C gives the 
disk-statistics on the C-Disk (as STAT S_ does the standard. 
S-Disk), and LISTF filename filetype cC lists the cC-Disk 
Files just as LISTF filename filetype S does the standard 


S-Disk files. 


CMS CONSIDERATIONS 
FORMATTING THE P-DISK 


Once the CMS System disk is restored and all device 
addresses are assured correct in matching either the bare 
machine configuration or the CP allocation a issue 
an IPL to the nae es disk. 


| Initially, each user must issue as his first command 
FORMAT P ALL. This command formats his P-Disk for CMS usage. 
If the disk is not formatted, I/O errors occur when 
accessing the P-disk. 


Note. All disks that are to be accessed by users must 
be formatted in the same manner as above. 


CMS VERSION 3--VERSION 2 COMPATIBILITY - 


The disk formats for Version 2 and Version 3 are 
compatible; however, the internal core tables are 
incompatible between these two versions of CMS. 


| Do not use old commands from Version 2 Levels 0 and 1 
which manipulate files with Version 3 (such as LOGIN, LISTF, 
OFFLINE, ERASE, TAPE, DISK, FORMAT, and START) as they do 
not work. | | | : | 

If a previous version of CMS is to be examined, log it 


in as a C-disk so that it will be searched last and its 
routines will not be used in place of the system routines. 


OBTAINING A NUCLEUS LOAD MAP 


A load map of the nucleus, giving the name and core 
location of each nucleus routine, may be obtained by 


IPL 190 (CMS system disk) 


| login on any formatted P-disk 
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MAPPRT C OFF (see other options for this 
command in CP-67/CMS User's Guide) 


The file CMS-NUC ALPHANUM Pi is created on the P-disk and is 
also printed offline. 


P-~DISK CONSIDERATIONS FOR THE BARE MACHINE 


When operating on the bare machine, the P-disk is used 
from real cylinder 0. Therefore, if a user wishes to use 
his own files on the bare machine, his files must be 
physically located on real cylinder 0. 


The user must also be aware of his P-disk size when he 
1s operating on the bare machine. CMS is not aware of the 
user's virtual boundaries and assumes a full physical disk 
pack; it will allow the user to format all 203 cylinders of 
the disk pack. 


COMMAND ABBREVIATIONS 


When a CMS command is issued from the terminal or from 
a routine, several tables are searched for the command name. 
If no command is defined for the name, CMS assumes that a 
command abbreviation was used. The nucleus-resident routine 
ABBREV is then searched to verify and find the full-name 
equivalent of the command. Command abbreviation is defined 
as the minimum number of characters necessary to recognize 
the full command name. 


If standard system abbreviations are not to be allowed 
in CMS, the ABBREV TEXT deck should be removed from the 
nucleus deck. 


To change, add, or delete an abbreviation, the ABBREV 
routine must be reassembled, altering the abbreviation table 
as desired. The table is constructed using the macro ABRV 
as follows: 


ABRV name, number 
where name is the full name of the command, and number is 


the minimum number of characters which are accepted as an 
abbreviation. 
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The macro must be used for each desired command 
abbreviation. For example: 


ABRV OFFLINE, 1 


Signifies that the acceptable abbreviation for the command 


OFFLINE is O (also, OF, OFF, OFFL, ...). 


ABRV ALTER, 2 


states that the abbreviation for ALTER is AL (also, ALT, 
ALTE, ALTER). | 


INSTALLATION OF THE CMS BATCH MONITOR 


Using the CMS System disk as a P-disk, obtain a copy of 
the Batch Monitor Nucleus, BATNUC 3.1, by issuing the 
command OFFLINE PUNCH BATNUC 3.1. A copy of the Batch 
nucleus may also be placed in the virtual card reader of 
USERA by issuing the command: NUCLEUS EXEC PUNCH USERA 


BATCH 


Set up a disk area that is used only by the virtual 
batch machine. This disk area, address cuu, contains’ the 
IPL‘able copy of Batch nucleus and need be only two-2314 
cylinders, or four-2311 cylinders. Also, set up a P-disk, 
191, for the Batch machine. 


Write an IPL‘able copy of the Batch nucleus onto disk 
cuu in the same manner as the CMS nucleus is reloaded onto 
the System disk. | 


After writing the Batch nucleus onto cuu, the message 
READY is typed. The Batch Nucleus disk, cuu, must be [PL‘*ed 


before executing any Batch Job Streams. 


To run a CMS Batch job stream, first it is necessary to 
IPL cCUU. The Batch nucleus may also be SAVE‘d by CP, using 
the name BATCH. If the name BATCH is undesirable, a 
different name may be used by changing the CP routine 
SYSTEM, which contains the names and descriptions of all 
IPL‘able named systems. Batch nucleus has set a time limit 
per job (five minutes) and an output limit per job (5000 
pointer lines). These limits may be modified by 
reassembling the routine BATJCB and placing the new copy 
into the BATCH nucleus. 


ee 
BE 





SAMPLE PROBLEM 


A sample problem is distributed as File 3 on the Source 
Disk tape. It exists in TAPE DUMP form. 


To load the sample problem onto the P-disk, position 
the tape after the second tape mark and load it from tape. 
This is done by issuing 

TAPE REWIND 
TAPE SKIP 2 
TAPE LOAD 
Then the program is ready to be compiled and executed. 


The complete procedure for logging in, IPL‘ing 190 for 
CMS, FORMAT‘ing the P-disk, loading the FORTRAN source deck 
on the P-disk, and then compiling and executing the sample 
problem as shown in Figure 2. System responses are printed 
in uppercase; user-entered information is typed in 
lowercase. Figure 3 contains a listing of the file SAMPLE 
FORTRAN. 
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login useri 
ENTER PASSWORD: 


READY AT 15.30.22 ON 2/15/71 


DEV 181 ATTACHED | 


ipl 190 


~ 68 =- 


CMS .. VERSION 3 LEVEL 0 


format p all | | | 

** “FORMAT P" WILL ERASE ALL YOUR P-DISK (191) FILES *¥* 
**#DO YOU WISH TO CONTINUE? ENTER “YES" OR "NO": 

yes | ? st 
ENTER 6-BYTE LABEL (IF WANTED), OR NULL LINE (IF NOT): 


FORMATTING P-DISK (2314)... 
P(191): 007 CYL | 
R; T=0.10/2.20 15.33.55 


tape rewind 
R; T=0.02/0.05 15.34.15 


tape skip 2 
R; T=0.20/0.57 15.35.00 


tape load 

LOADING: | 
SAMPLE FORTRAN P1 LOADED 
R; T=0.15/0.32 15.35.25 


fortran sample — 
R; T=0.58/0.92 15.35.59 


S$ sample 
EXECUTION BEGINS. .. 
PLEASE TYPE IN THE NUMBER OF VALUES TO AVERAGE 


03 

FIRST NUMBER? (FORMAT is F10.4) 
45.6 

NEXT NUMBER? 
56.7 

NEXT NUMBER? 
49.09 

AVERAGE = 50.4633 
PLEASE TYPE IN THE NUMBER OF VALUES TO AVERAGE 

00 


*** TEST COMPLETE *** WELCOME TO eeroneCl? 
R; T=0.36/1.06 15.37.15 


Figure 2. Terminal session with the sample problem 








102 


103 


104 


99 
106 


SAMPLE PROBLEM FOR TESTING CP-67/CMS DISTRIBUTION 


PRINT 100 

FORMAT ('° PLEASE TYPE IN THE NUMBER OF VALUES TO AVERAGE") 
READ 101, N 

FORMAT (12) 

IF (N) 2,99,2 

PRINT 105 

FORMAT (° FIRST NUMBER? (FORMAT IS F10.4)") 

READ 103, SUM 


M=N-1 
DO 3 I=1,M 
PRINT 102 


FORMAT (* NEXT NUMBER?* ) 
READ 103, X 

FORMAT (F10.4) 

SUM = SUM + X 

CONTINUE 

Y=N 

AVG = SUM/Y 

PRINT 104, AVG 


FORMAT (15X, ‘AVERAGE = ',F10.4) 

GO TO 1 

PRINT 106 

FORMAT (‘ *** TEST COMPLETE *** WELCOME TO CP-67/CMS! *) 
STOP 

END 


Figure 3. Listing of SAMPLE FORTRAN 
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*2311,2314 192**  DSK3 temporary disk (workspace) 
*2311,2314 OO00** DSK4 A disk (user files) 
*2311,2314 O00** DSK5 — B disk (user files) 
*2311,2314 19C** DSK6 C disk (user files) 

1403 OOE PRN1 line printer 

2540 00C RDR1 card reader 

2540 OOD PCH1 card punch 

*2400,3420 180 TAP1 tape drive 

*2400,3420 181 TAP2 tape drive 
* The 2311 or 2314 for the temporary disk, the A, B, and 


| Cc disks, and the two tape drives are optional devices; 
‘ they are not included in the minimum configuration. 


** The reference between the virtual address and I/0 
device may be changed at any time by the CMS’ LOGIN 
command. : 


After entering the real device addresses, the CMS 
initialization message is typed 
CMS .. VERSION n LEVEL m 
Issue the CMS command 
‘ | FORMAT P ALL 
to format the P-disk to be used for CP-67 SYSGEN. The 


card punch and printer should be placed in READY 
Status. 


Place the CP distribution tape on symbolic drive 
TAP2 and issue 
TAPE LOAD 4 
‘ All necessary CP files are loaded onto the P-disk. 


These files are of the following filetypes for 
generation of CP-67 and the utilities: 


SYSIN files, which are the CP source decks written in 
Assembler Language; 


EXEC files, which contain procedures for assembling and 


updating; 
TEXT files containing the assembled modules of the 
system; 

( MACLIB files containing CP-67 macros for assembling the 


system and the real machine configuration; 


ASP360 and COPY files for creating and changing the 
macro library CPMACS MACLIB, when necessary; 


LOADER files containing relocating loaders with 
different printer addresses (that is, 000, OOE, OOF, 
010, 030, O40); . | 


SAMPLE files containing examples of the various decks 


required for system setup. 


It is from this P-disk (on which the above CP files are 
loaded) that the CP system is obtained. 


Note. While executing CMS onthe real machine, the last 


card of any punched deck must be manually run out from the 
card punch. 


MACHINE CONFIGURATION DEFINITION 
FOR CP-67 | 


A description of the physical machine must be provided 
for CP-67. This description is contained in a SYSIN or 
source deck called RIOxxx, where xxx are any three 
characters specified by the installation. This SYSIN deck 
1s assembled via the CMS ASSEMBLE command, and the resultant 
text or object deck placed in the CP-67 system. Same 
Simplex and duplex machine configurations are distributed 
among the P-disk files with the identifiers of RIOCSC SYSIN, 
SIMPLEX SAMPLE, and DUPLEX SAMPLE. If the distributed 
RIOcCSC SYSIN does not meet the installation's configuration, 
a new RIOxxx deck must be constructed from the macros below, 
assembled, and used in place of the distributed RIOCSC text 
deck. : 


To get the real I/0 definitions for the target 
configuration read onto the P-disk, from the card reader, 
place the RIOxxx deck into the reader, ready it, and issue 
the CMS command | 


OFFLINE READ RIOxxx SYSIN 


where xxx are any three characters specified by the 
installation. If CSC is chosen for xxx, the existing file 


RIOCSC SYSIN is erased. 


To assemble the real I/O configuration deck, produce 
the text deck, and print the listing, issue the CMS command 
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unit; cis the control unit address; path is the value 
(hexadecimal) of the logical path for this control unit 
(each control unit on a channel has a unique bit of the 
eight bits assigned to the channel and this bit or path 
defines which devices are accessed through this’ control 
unit); taill provides a connection to this control unit from 
the channel--use the symbolic label of the channel on which 
this control unit resides. | 


Cefine Device Macro 


[label| DRDEV | RDEVPNT=<0,dlabel>|, 
RDEVCU=culabel, RDEVADD=ccu, 
TYPE=type,DECUPTH=path, 


where “label™ is the symbolic label for this device; dlabel 
is the symbolic label of the next device on this control 
unit; culabel is the label of the control unit on which 
this device resides; ccu is the channel, control unit, and 
unit address of this device; type is the device type 
(specified as xxxx where xxxx is 2311, 2314, 2321, 2301, 
2303, 2400, 3420, 1403, 2540P, 2540R, 2701, 2702, 2703, 

or 2250; "path" is identical to the control units path 
(RCUPATH in DRCU) for this device and defines which con- 
trol unit this device uses. 


Define Multiplexor Device Macro 


s 
{label| DMXDV RDEVADD=ccu,TYPE=type, |SAD=n|, 
| | RDEVPNT=<0,mlabel>| 


where “label"™ is the symbolic label of this multiplexor 
device; ccu is the channel, control unit, and unit address 
of this device; type is the device type, which is_- one of 
the following: 1052, 1403, 2540RDR, 2540PCH, 2701T, 2702T, 
2703T, or MTT35T ( where the 2701T, 2702T, 2703T implies a 
1052, 2741-BCD or 2741-correspondence terminal coming into a 
2701, 2702, or 2703 and the TT35T is a teletype 33 or 35); n 
is the SAD address of the 2701, 2702, or 2703 and has a> 
value of 0, 1, 2, 3, or 4 (the SAD address does not indicate 
terminal type); For a 2701 which does not require a_ SAD 
command, specify a value of 4. For a 2703 which ignores SAD 
commands, a value of 4 can also be specified. For a 2702, 
the correct SAD value for the particular line must _ be 
Specified (0, 1, 2, and 3 are valid). Your local IBM CE 


can supply you with the SAD numbers for each 2702 line; and 
mlabel is the symbolic label of the next multiplexor device 
in the chain. There must be one DMXDV macro defined for each 
2701, 2702, or 2703 line. | 


Note. The ordered arrangement of the real I/O macros is 
required to properly generate the correct entries. and 
tables. 


The multiplexor devices must be defined before the 
selector channel devices. Each selector channel must _ be 
completely defined in terms of devices, control unit, and 
then channel (in that order) before the next selector 
channel is defined. If a simplex configuration is being 
described, the SIMPLEX macro must be followed by the END 
card. If a duplex configuration is being described, two 
SIMPLEX macros are required: the first SIMPLEX macro is 
followed by the I/O definitions for another CPU; the second 
SIMPLEX macro is followed by the END card. 


An example of a real I/O source deck for a_ simplex 
configuration is as follows: 


RIOS REALIO TITLE=*SAMPLE SIMPLEX‘ 

OPCONSOL DMXDV RDEVPNT=PRINTER1 , RDEVADD=009, TYPE=10 52 
PRINTER1 DMXDV RDEVPNT=CARDRDRI1 , RDEVADD=030, TY PE=1403 
CARDRDR1i DMXDV RDEVPNT=PUNCH1 , RDEVADD=031,TYPE=2540RDR 
PUNCH1 DMXDV RDEVPNT=TERM01 , RDEVADD=032, TY PE=2540 PCH 
TERMO1 DMXDV RDEVPNT=TERMO2, RDEVADD=020, TYPE=2702T,SAD=1 
TERMO2 DMXDV RDEVPNT=TERMO3 , RDEVADD=0 21, TY PE=2702T,SAD=1 
TERMO3 DMXDV RDEVPNT=TERMO4, RDEVADD=023, TYPE=TT35T, SAD=2 


TERMYE DMZDV RDEVADD=04E, TYPE=27 03T, SAD=4 

DRUM 2 DRDEV RDEVCU=R2820A, RDEVADD=1 00, TYPE=2301, DECUPTH=80 

R2820A DRCU DEVLIST=DRUM2, RCUADD=0, CUTAILI=CHAN1 , RCUPATH=80 

CHAN1 DRCH RCULIST=R2820A, CHANADD=1 , CHANPNT=CHAN2 

DISK30 DRDEV RDEVCU=R2314, RDEVADD=230, TY PE=2314, DECUPTH=40, 
RDEVPNT=DISK31 

DISK31  DRDEV RDEVCU=R2314,RDEVADD=231, TYPE=2314,DECUPTH=40, 
RDEVPNT=DISK32 


DISK37 DRDEV RDEVCU=R2314, RDEVADD=237, TYPF=2314, DECUPTH=40 

R2314 DRCU DEVLIST=DISK30, RCUADD=3 , CUTATL1=CHAN2 , RCUPATH=40 

CHAN 2 DRCH RCULIST=R2314,CHANADD=2 , CHANPNT=CHAN3 

DRUM1 DRDEV RDEVCU=R2841B, RDEVADD=393, TY PE=2303, DECUPTH=80, 
RDEVPNT=DISK4 

DISK4 DRDEV RDEVCU=R2841B, DEVADD=390, TYPE=2311, DECUPTH=80, 
~RDEVPNT=DISK5 
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| ,RDSHAR=password | 
| ,WRMULT | 


| ,-WRSHAR=password | 


The UNIT card is used to specify the input/output units 
available to a user and where and on which volumes his 
permanent files reside. 


ccu is the virtual address of the device. 


devtype is the device type, which may be one of 
the following: 


1052 
2540P 
2540R 
1403 
2250 
2311 or 2312 
2314 
2400 
3420 
2701 
2702 
2103 
TIMR 
RPRT 
RPUN 


where a 2312 is used to designate the 
bottom half of a 2314 drive used as a 
virtual 2311. 


A 2312 device type is treated as a 2311 by CP-67. User seek 
commands issued to the pseudo 2311 have the head address 
relocated (by adding decimal 10) to access the bottom half 
of the 2314 disk. It should be noted that 2311 device types 
Supported on the top half of a 2314 pack may experience 
difficulties if multitrack Operations are attempted; 
however, multitrack operations on the 2312 (pseudo 2311) 
device type should work correctly since a physical 
end-of-cylinder condition is recognizable. 


TIMR is a pseudo-timer device which can provide the time of 
day, date, virtual CPU time, and total CPU time to a virtual 
machine. It should be specified for every CMS user. Its 
format is 


UNIT OFF,TIMR 


RPRT and RPUN are special device types that allow the user 
to access the disk dump created by a CP-67 system abend. 


For the desired userid to receive the dump (see section on 
VDUMP) specify 
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UNIT OF1,RPRT 


XXXXXX_ is the volume label of the disk that is being 
described. 
(TEMP) specifies that the disk space is to be 


obtained at logon time from that allocated as TDSK 
Space andthen removed from the user at CP-67 
logoff. | . 


REM=IDccu specifies a remote device with real address 
ccu that is to be used for spooled output from 
this defined user. It has the same function as 
the SPOOL console commands for directing spooled 
output. See CP-67/CMS User's Guide for details. 
The only device types supported as remote devices 
are the 2540P and the 1403. 


DED=IDccu specifies a device with real address ccu that 
is dedicated to this user at login time and 
unavailable to other users. The device types 
supported are the 1403, 2540R, 2540P, 2250, 2400, 
2701, 2702, and the 2703. If the specified device 
1S not available or in use when the user logs in, 
he is so informed and the device is not attached 
to him. Note that a 2250 or 2400, if specified, 
must be defined as a dedicated device. 


CON=YES specifies that continuous spooled input is 
desired for this virtual card reader; that is, if 
there is more than one spooled input file for the 
card reader, they are read as one continuous file 
before end-of-data 1s given. This has the same 

function as the SPOOL ccu CONT console function 
(see CP-67/CMS User's Guide for details.) 


relno ‘is a three-digit decimal cylinder relocation 


factor to be applied to this device; for example, 
if a user's permanent files started at cylinder 54 
of the specified volume, relno would be specified 
as 054. | 


zzz is a three-digit decimal number specifying the 
number of temporary cylinders to be obtained at 
logon. zzz is used only if (TEMP) was specified. 


last is a three-digit decimal number specifying the 
last cylinder of the user's file space. If relno 
is 054 and the user is allowed 20 cylinders of 
Space, last would be specified as 073. 


